pg_class
The catalog pg_class
catalogs tables and most
everything else that has columns or is otherwise similar to a
table. This includes indexes (but see also pg_index
),
sequences (but see also pg_sequence
),
views, materialized views, composite types, and TOAST tables;
see relkind
.
Below, when we mean all of these kinds of objects we speak of
“relations”. Not all columns are meaningful for all relation
types.
Table 53.11. pg_class
Columns
Column Type Description |
---|
Row identifier |
Name of the table, index, view, etc. |
The OID of the namespace that contains this relation |
The OID of the data type that corresponds to this table's row type,
if any; zero for indexes, sequences, and toast tables, which have
no |
For typed tables, the OID of the underlying composite type; zero for all other relations |
Owner of the relation |
If this is a table or an index, the access method used (heap, B-tree, hash, etc.); otherwise zero (zero occurs for sequences, as well as relations without storage, such as views) |
Name of the on-disk file of this relation; zero means this is a “mapped” relation whose disk file name is determined by low-level state |
The tablespace in which this relation is stored. If zero, the database's default tablespace is implied. (Not meaningful if the relation has no on-disk file.) |
Size of the on-disk representation of this table in pages (of size
|
Number of live rows in the table. This is only an estimate used by
the planner. It is updated by |
Number of pages that are marked all-visible in the table's
visibility map. This is only an estimate used by the
planner. It is updated by |
OID of the TOAST table associated with this table, zero if none. The TOAST table stores large attributes “out of line” in a secondary table. |
True if this is a table and it has (or recently had) any indexes |
True if this table is shared across all databases in the cluster. Only
certain system catalogs (such as |
|
|
Number of user columns in the relation (system columns not
counted). There must be this many corresponding entries in
|
Number of |
True if table has (or once had) rules; see
|
True if table has (or once had) triggers; see
|
True if table or index has (or once had) any inheritance children or partitions |
True if table has row-level security enabled; see
|
True if row-level security (when enabled) will also apply to table owner; see
|
True if relation is populated (this is true for all relations other than some materialized views) |
Columns used to form “replica identity” for rows:
|
True if table or index is a partition |
For new relations being written during a DDL operation that requires a table rewrite, this contains the OID of the original relation; otherwise zero. That state is only visible internally; this field should never contain anything other than zero for a user-visible relation. |
All transaction IDs before this one have been replaced with a permanent
(“frozen”) transaction ID in this table. This is used to track
whether the table needs to be vacuumed in order to prevent transaction
ID wraparound or to allow |
All multixact IDs before this one have been replaced by a
transaction ID in this table. This is used to track
whether the table needs to be vacuumed in order to prevent multixact ID
wraparound or to allow |
Access privileges; see Section 5.7 for details |
Access-method-specific options, as “keyword=value” strings |
If table is a partition (see |
Several of the Boolean flags in pg_class
are maintained
lazily: they are guaranteed to be true if that's the correct state, but
may not be reset to false immediately when the condition is no longer
true. For example, relhasindex
is set by
CREATE INDEX
, but it is never cleared by
DROP INDEX
. Instead, VACUUM
clears
relhasindex
if it finds the table has no indexes. This
arrangement avoids race conditions and improves concurrency.