5.4. System Columns

5.4. System Columns

5.4. 系统列

Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot be used as names of user-defined columns. (Note that these restrictions are separate from whether the name is a key word or not; quoting a name will not allow you to escape these restrictions.) You do not really need to be concerned about these columns; just know they exist.

每张表均有几列由系统隐式定义的系统列。因此,它们的名称不能用作用户自定义列名。(请注意,此限制与名称是否为关键字无关;即使将该名称引起来,依旧会有此限制。)其实你无需关心这些列,只是知道它们存在即可。

oid

The object identifier (object ID) of a row. This column is only present if the table was created using WITH OIDS, or if the default_with_oids configuration variable was set at the time. This column is of type oid (same name as the column); see Section 8.19 for more information about the type.

行的对象标识(对象ID)。只有当表在创建时指定WITH OIDS选项或者设置了default_with_oids配置变量,此列才会存在。此列的数据类型是oid(与列名相同);关于此数据类型的详细信息,请查看第8.19节

tableoid

The OID of the table containing this row. This column is particularly handy for queries that select from inheritance hierarchies (see Section 5.9), since without it, it's difficult to tell which individual table a row came from. The tableoid can be joined against the oid column of pg_class to obtain the table name.

含此行的表OID。 对于从继承层次结构中进行的查询,该列特别方便(请参见5.9节),因为如果没有它,则很难确定一行来自哪个表。 可以将tableoid与pg_class的oid列关联以获得表名。

xmin

The identity (transaction ID) of the inserting transaction for this row version. (A row version is an individual state of a row; each update of a row creates a new row version for the same logical row. )

对于此行版本的插入事务中的标识(事务ID)。(行版本是行的私有状态;行的每次更新对会对相同逻辑行创建一个新的行版本。)

cmin

The command identifier (starting at zero) within the inserting transaction.

插入事务的命令标识(从0开始)。

xmax

The identity (transaction ID) of the deleting transaction, or zero for an undeleted row version. It is possible for this column to be nonzero in a visible row version. That usually indicates that the deleting transaction hasn't committed yet, or that an attempted deletion was rolled back.

删除事务的标识(事务ID),或者如果是未删除的行版本,则为0。对于可见行版本,此列也可能是一个非0值。这一般说明,删除事务还没有提交,或者删除被回滚了。

cmax

The command identifier within the deleting transaction, or zero.

删除事务的命令标识,或者是0。

ctid

The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change if it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows.

表中行的物理地址。请注意,虽然ctid可以可以快速定位行版本,行的ctid可能会因为更新而改变,或者因为VACUUM FULL而移除。因此,如果将ctid作为长期行标识是不明智的。建议使用OID或者用户定义的序列号来标识逻辑行。

OIDs are 32-bit quantities and are assigned from a single cluster-wide counter. In a large or long-lived database, it is possible for the counter to wrap around. Hence, it is bad practice to assume that OIDs are unique, unless you take steps to ensure that this is the case. If you need to identify the rows in a table, using a sequence generator is strongly recommended. However, OIDs can be used as well, provided that a few additional precautions are taken:

OID是一个由群集范围的计数器分配的32位数字。在一个大型或者长期存在的数据库中,计数器有可能会回绕。因此,除非采取措施保证OID唯一,否则假定OID是唯一的并不明智。如果你想要在表中标识一行,强烈建议使用序列。然而,在采取一些预防措施的前提下,也可以使用OID:

• A unique constraint should be created on the OID column of each table for which the OID will be used to identify rows. When such a unique constraint (or unique index) exists, the system takes care not to generate an OID matching an already-existing row. (Of course, this is only possible if the table contains fewer than 232 (4 billion) rows, and in practice the table size had better be much less than that, or performance might suffer.)

• OIDs should never be assumed to be unique across tables; use the combination of tableoid and row OID if you need a database-wide identifier.

• Of course, the tables in question must be created WITH OIDS. As of PostgreSQL 8.1, WITHOUT OIDS is the default.

  • 在要标识行的OID列上创建唯一索引。当此唯一约束(或者唯一索引)存在了,系统将不会生成与现有行匹配的OID。(当然,这仅当表含有少于2的32次方(40亿)的行的时候可用,不然的话性能会有很大影响。)

  • 跨表OID始终不应该被认为是唯一的;如果需要数据库级别的标识,建议使用tableoid和行OID。

  • 当然,讨论中的表创建的时候需要制定WITH OIDS选项,在PostgreSQL8.1中,默认选项为WITHOUT OIDS。

 Transaction identifiers are also 32-bit quantities. In a long-lived database it is possible for transaction IDs to wrap around. This is not a fatal problem given appropriate maintenance procedures; see Chapter 24 for details. It is unwise, however, to depend on the uniqueness of transaction IDs over the long term (more than one billion transactions).

事务标识也是32位数字。在一个长事务中,事务ID可能会回绕。只要维护得当,这并不是一个严重问题,详情参见第24章。然而,长期依赖事务ID的唯一性是不明智的(超过10亿事务)。

Command identifiers are also 32-bit quantities. This creates a hard limit of 232 (4 billion) SQL commands within a single transaction. In practice this limit is not a problem — note that the limit is on the number of SQL commands, not the number of rows processed. Also, only commands that actually modify the database contents will consume a command identifier.

命令标识也是32位数字。在单一事务中,强制限制SQL命令在2的32次方(20亿)内。实际中,此限制其实并不是问题--因为此限制是SQL命令的个数,而不是处理的行的条数。当然,只有那些实际修改了数据库内容的命令才被认为是命令标识。

发布了341 篇原创文章 · 获赞 53 · 访问量 88万+

猜你喜欢

转载自blog.csdn.net/ghostliming/article/details/104356125