pg_class
Le catalogue pg_class
décrit les tables, et
les autres objets qui contiennent des colonnes ou ressemblent
à une table. Cela inclut les index (mais il faut aussi aller voir dans pg_index
), les
séquences (mais voir aussi pg_sequence
),
les vues, les vues matérialisées, les types
composites et les tables TOAST ; voir
relkind
.
Par la suite, lorsque l'on parle de « relation », on
sous-entend tous ces types d'objets. Les colonnes de
pg_class
ne sont pas toutes
significatives pour tous les types de relations.
Tableau 52.11. Colonnes de pg_class
Type Description |
---|
Identifiant de ligne |
Nom de la table, vue, index, etc. |
OID du namespace qui contient la relation. |
OID du type de données qui correspond au type de ligne de la table,
s'il y en a un.
0 pour les index, séquences et tables TOAST qui n'ont pas d'entrée
dans |
Pour les tables typées, l'OID du type composite sous-jacent. Sinon, 0 dans tous les autres cas. |
Propriétaire de la relation. |
S'il s'agit d'une table ou d'un index, méthode d'accès utilisée (B-tree, hash, etc.) ; sinon zéro (cela arrive pour les séquences ainsi que pour les relations sans stockage, telles que les vues) |
Nom du fichier disque de la relation ; zéro signifie que c'est une relation « mapped » dont le nom de fichier est déterminé par un statut de bas niveau. |
Le tablespace dans lequel est stocké la relation. Si 0, il s'agit du tablespace par défaut de la base de données. Sans intérêt si la relation n'a pas de fichier sur disque, sauf pour les tables partitionnées, où il s'agit du tablespace dans lequel les partitions sont créées so aucun tablespace n'est précisé dans la commande de création. |
Taille du fichier disque, exprimée en pages (de taille
|
Nombre de lignes de la table.
Ce n'est qu'une estimation utilisée par le planificateur. Elle est
mise à jour par |
Nombre de pages marquées entièrement visibles dans la carte de visibilité
de la table. Ceci n'est qu'une estimation utilisée par le planificateur.
Elle est mise à jour par |
OID de la table TOAST associée à cette table. Zéro s'il n'y en a pas. La table TOAST stocke les attributs de grande taille « hors ligne » dans une table secondaire. |
Vrai si c'est une table et qu'elle possède (ou possédait encore récemment) quelque index. |
Vrai si cette table est partagée par toutes les bases de données
du cluster. Seuls certains catalogues système (comme
|
|
|
Nombre de colonnes utilisateur dans la relation (sans compter les
colonnes système). Il doit y avoir le même nombre d'entrées dans
|
Nombre de contraintes de vérification ( |
Vrai si la table contient (ou a contenu) des règles ; voir le catalogue
|
Vrai si la table a (ou a eu) des triggers ; voir le catalogue
|
Vrai si au moins une table ou un index hérite ou a hérité d'un enfant |
Vrai si la table a la sécurité niveau ligne activée ; voir
le catalogue |
Vrai si la sécurité niveau ligne (si activée) s'appliquera aussi au propriétaire de la table ; voir
le catalogue |
Vrai si la relation est peuplée (ceci est vrai pour toutes les relations autres que certaines vues matérialisées) |
Colonnes utilisées pour former une « identité de réplica »
pour les lignes :
|
True si la table ou l'index est une partition |
Pour les nouvelles relations écrites lors d'une opération DDL qui requiert une réécriture de la table, cette colonne contient l'OID de la relation originale ; zéro sinon. Cet état est seulement visible en interne ; ce champ ne devrait jamais contenir autre chose que zéro pour une relation visible par l'utilisateur. |
Tous les ID de transaction avant celui-ci ont été remplacés par un ID de
transaction permanent (« frozen »). Ceci est utilisé pour
déterminer si la table doit être nettoyée (VACUUM) pour éviter un
bouclage des ID de transaction
(ID wraparound) ou pour compacter
|
Tous les identifiants MultiXact avant celui-i ont été remplacés
par un identifiant de transaction dans cette table. Ceci est utilisé pour
tracer si la table a besoin d'être traitée par le VACUUM pour empêcher
un bouclage des identifiants MultiXact ou pour permettre à
|
Droits d'accès ; voir Section 5.7 pour plus de détails. |
Options spécifiques de la méthode d'accès, représentées par des chaînes du type « motclé=valeur » |
Si la table est une partition (voir |
Plusieurs des drapeaux booléens dans pg_class
sont
maintenus faiblement : la valeur true est garantie s'il s'agit du bon
état, mais elle pourrait ne pas être remise à false immédiatement quand la
condition n'est plus vraie. Par exemple,
relhasindex
est configurée par
CREATE INDEX
mais
n'est jamais remise à false par DROP
INDEX
. C'est VACUUM
qui le fera
relhasindex
s'il découvre que la table n'a pas
d'index. Cet arrangement évite des fenêtres de vulnérabilité et améliore
la concurrence.