postgresql的系统列(system cloumns)

每种数据库中都保留了自己所有的关键字,在表的定义过程中同样数据库保存了自己的系统列。看完关于postgresql的系统列部分的文档,还勾起了我想了解postgresql事务如何进行管理的冲动。先对postgresql的系统列进行一下了解,重要的是从中得到一些设计思想上的东西。
对于系统的保留关键字,都是禁止或者不建议用户进行定义时使用的词语。postgresql中的系统列是不允许作为用户定义的列名字段,在现实数据库设计过程中很少使用这些字段名称,所以不需要特别的关注,需要知道它们的存在。

oid
行对象表示符。postgresql为每个表的所有列自动添加该值(除非创建表时采用WITHOUT OIDS选项,该情况下oid列不显示),该列与类型同名。
在oracle中有rowid列,正常情况下是不显示的,也是系统自动生成的值,不是主角不多说。

tableoid
表对象表示符。该列对于从继承层次中进行查询非常有用,如果没有它,就很难说清行记录来自那个表。tableoid列与数据字典pg_class的oid进行关联可以获取表名。
oracle中似乎没有tableoid专有列名,同样可以通过user_objects视图查到表的id,对于判断行属于哪一列,oracle将对象的id号直接放到了rowid中。
oracle的rowid采用64进制表示方式,由18个字符表示:对象编号的6字符+文件编号的3字符+块编号的6字符+行编号的3字符,就是说直接找到行就能知道它属于那个文件,那个对象,在那个块上。

xmin
行版本的插入事务标识。(行版本代表着行的状态,行的每次更新会创建新的版本。)
如果对postgresql的事务管理设计方式不了解,很难清楚这个东西如何工作的。接下来可以好好了解一下事务的管理方式。

cmin
插入事务内的命令标识。(该值从0开始)。
这个更难理解了,插入事务能有多少命令标识?可以推测一下插入的方式不同该值可能不同,还是插入操作所处于不同的状态?,还是需要去了解事务的管理方式。

xmax
删除事务标识。对于非删除的行版本该值是0。该值为非0值时表示删除事务还没有提交,或者试图进行回滚。
也就是说明了该参数值至少有三种,用于表示删除处于的状态。

cmax
删除事务内部的命令标识,或者为0。

ctid
行版本在表中的物理位置。尽管ctid能够快速实现定位版本,但是经过VACUUM FULL之后,行的ctid就会移动或者更新。由此ctid不适于作行的行的长期标识符。
ctid表示的物理位置,如果VACUUM执行发生了行数据的物理移动,那索引又要如何?索引中指向表行位置的id又如何变化,目前对VACUUM没有深入了解,只能猜想是跟着变化。

文档中提到OID是32位的。很难对oid的唯一性作出假设。
事务标识与命令标识都是32位。

虽然从几个关键字很难解释事务管理方式,但是从中也能窥探一点。对象都是存放在文件中的,对象与文件之间又是如何关联在一起的?会不会也象oracle的rowid一样包含着文件号?tableoid与行之间的关系如何?弄清楚这些问题后,对postgresql对数据记录如何进行定位的问题也就能够了解很多。看来要了解更多的postgresql知识需要解决不少问题。

 

参考文档:http://www.postgresql.org/docs/8.0/interactive/ddl-system-columns.html

posted on 2010-08-12 12:37  大肚熊  阅读(1505)  评论(0编辑  收藏  举报

导航