PostgreSQL a la possibilité de rapporter la
progression de certaines commandes lors de leur exécution. Actuellement,
les seules commandes supportant un rapport de progression sont
CREATE INDEX, VACUUM et
CLUSTER. Ceci pourrait être étendu dans le futur.
Quand un CREATE INDEX ou un REINDEX
est en cours d'exécution, la vue
pg_stat_progress_create_index contient une ligne
pour chaque processus serveur en train de créer des index. Les tables
ci-dessous décrivent les informations rapportées et fournissent des
informations sur leur interprétation.
Tableau 27.22. Vue pg_stat_progress_create_index
| Colonne | Type | Description |
|---|---|---|
pid | integer | Identifiant du processus serveur. |
datid | oid | OID de la base de données de connexion du processus. |
datname | name | Nom de la base de données de connexion du processus. |
relid | oid | OID de la table liée à l'index en cours de création. |
index_relid | oid | OID de l'index en cours de création ou de réindexation. Lors d'un
CREATE INDEX non concurrent, cette colonne vaut 0. |
command | text |
La commande en cours d'exécution : CREATE INDEX,
CREATE INDEX CONCURRENTLY,
REINDEX ou REINDEX CONCURRENTLY.
|
phase | text | Phase en cours de traitement pour la création de l'index. Voir Tableau 27.23. |
lockers_total | bigint | Nombre total de processus bloquant à attendre, si applicable. |
lockers_done | bigint | Nombre de processus bloquant déjà attendus. |
current_locker_pid | bigint | Identifiant du processus bloquant actuellement. |
blocks_total | bigint | Nombre total de blocs à traiter dans la phase en cours. |
blocks_done | bigint | Nombre de blocs déjà traités dans la phase en cours. |
tuples_total | bigint | Nombre total de lignes à traiter dans la phase en cours. |
tuples_done | bigint | Nombre de lignes déjà traitées dans la phase en cours. |
partitions_total | bigint | Lors de la création d'un index sur une table partitionnée, cette colonne est configurée au nombre total de partitions sur lesquels l'index est créé. |
partitions_done | bigint | Lors de la création d'un index sur une table partitionnée, cette colonne est configurée au nombre total de partitions sur lesquels l'index a déjà été créé. |
Tableau 27.23. Phases du CREATE INDEX
| Phase | Description |
|---|---|
initializing |
CREATE INDEX ou REINDEX prépare
la création de l'index. Cette phase est normalement très brève.
|
waiting for writers before build |
CREATE INDEX CONCURRENTLY ou REINDEX
CONCURRENTLY attend que les transactions avec des verrous en
écriture qui peuvent voir la table se finissent Cette phase est ignorée
quand elle n'est pas en mode concurrent. Les colonnes
lockers_total,
lockers_done et
current_locker_pid contiennent les
informations de progression sur cette phase.
|
building index |
L'index est en cours de construction par le code spécifique de la
méthode d'accès. Dans cette phase, les méthodes d'accès qui supportent
les rapports de progression remplissent eux-même les données de
progression, et la sous-phase est indiquée dans cette colonne.
Typiquement, blocks_total et
blocks_done contiendront les données de
progression, ainsi que tuples_total et
tuples_done potentiellement.
|
waiting for writers before validation |
CREATE INDEX CONCURRENTLY ou REINDEX
CONCURRENTLY est en attente de la fin des transactions avec
verrous en écriture pouvant potentiellement écrire dans la table. Cette
phase est ignorée quand elle n'est pas en mode concurrent. Les colonnes
lockers_total,
lockers_done et
current_locker_pid contiennent les
informations de progression pour cette phase.
|
index validation: scanning index |
CREATE INDEX CONCURRENTLY parcourt l'index pour
trouver les lignes qui ont besoin d'être validées. Cette phase est
ignorée quand elle n'est pas en mode concurrent. Les colonnes
blocks_total (configurée à la taille totale de
l'index) et blocks_done contiennent les
informations de progression pour cette phase.
|
index validation: sorting tuples |
CREATE INDEX CONCURRENTLY trie la sortie de la phase
de parcours de l'index.
|
index validation: scanning table |
CREATE INDEX CONCURRENTLY parcourt la table pour
valider les enregistrements d'index collectés dans les deux phases
précédentes. Cette phase est ignorée quand elle n'est pas en mode
concurrent. Les colonnes blocks_total
(configurée à la taille totale de la table) et
blocks_done contiennent les informations de
progression pour cette phase.
|
waiting for old snapshots |
CREATE INDEX CONCURRENTLY ou REINDEX
CONCURRENTLY est en attente que les transactions pouvant
potentiellement voir la table relâchent leur snapshot. Cette phase est
ignorée quand elle n'est pas en mode concurrent. Les colonnes
lockers_total,
lockers_done et
current_locker_pid contiennent les
informations de progression pour cette phase.
|
waiting for readers before marking dead |
REINDEX CONCURRENTLY est en attente de la fin des
transactions avec verrous en lecture sur la table, avant de marquer
l'ancien index comme mort. Cette phase est ignorée quand elle n'est pas
en mode concurrent. Les colonnes
lockers_total,
lockers_done et
current_locker_pid contiennent les
informations de progression pour cette phase.
|
waiting for readers before dropping |
REINDEX CONCURRENTLY est en attente de la fin des
transactions avec verrous en lecture sur la table, avant de supprimer
l'ancien index. Cette phase est ignorée quand elle n'est pas en mode
concurrent. Les colonnes lockers_total,
lockers_done et
current_locker_pid contiennent les
informations de progression pour cette phase.
|
La vue pg_stat_progress_vacuum contient une ligne
pour chaque processus serveur (incluant les processus autovacuum worker) en
train d'exécuter un VACUUM. Les tableaux ci-dessous
décrivent les informations rapportées et fournissent des informations sur
leur interprétation. La progression des commandes VACUUM FULL
est rapportée par pg_stat_progress_cluster parce
que le VACUUM FULL comme le CLUSTER
réécrivent la table, alors qu'un VACUUM simple la modifie
directement. Voir Section 27.4.3.
Tableau 27.24. Vue pg_stat_progress_vacuum
| Colonne | Type | Description |
|---|---|---|
pid | integer | Identifiant (PID) du processus serveur. |
datid | oid | OID de la base de données où est connecté ce processus serveur. |
datname | name | Nom de la base de données où est connecté ce processus serveur. |
relid | oid | OID de la table nettoyée par le VACUUM. |
phase | text | Phase actuelle du vacuum. Voir Tableau 27.25. |
heap_blks_total | bigint |
Nombre total de blocs de la table. Ce nombre est récupéré au début du
parcours. Des blocs peuvent être ajoutés par la suie, mais ne seront
pas (et n'ont pas besoin d'être) visités par ce
VACUUM.
|
heap_blks_scanned | bigint |
Nombre de blocs parcourus dans la table. Comme la carte de visibilité est utilisée pour
optimiser les parcours, certains blocs seront ignorés sans
inspection ; les blocs ignorés sont inclus dans ce total, pour que
ce nombre puisse devenir égal à
heap_blks_total quand le nettoyage se
termine. Ce compteur avance seulement quand la phase est
scanning heap.
|
heap_blks_vacuumed | bigint |
Nombre de blocs nettoyés dans la table. Sauf si la table n'a pas
d'index, ce compteur avance seulement quand la phase est
vacuuming heap. Les blocs qui ne contiennent aucune
ligne morte sont ignorés, donc le compteur pourrait parfois avancer par
de larges incréments.
|
index_vacuum_count | bigint | Nombre de cycles de nettoyage d'index réalisés. |
max_dead_tuples | bigint | Nombre de lignes mortes que nous pouvons stocker avant d'avoir besoin de réaliser un cycle de nettoyage d'index, basé sur maintenance_work_mem. |
num_dead_tuples | bigint | Nombre de lignes mortes récupérées depuis le dernier cycle de nettoyage d'index. |
Tableau 27.25. Phases du VACUUM
| Phase | Description |
|---|---|
initializing |
VACUUM se prépare à commencer le parcours de la
table. Cette phase est habituellement très rapide.
|
scanning heap |
VACUUM parcourt la table. Il va défragmenter chaque
bloc si nécessaire et potentiellement réaliser un gel des lignes. La
colonne heap_blks_scanned peut être utilisée
pour surveiller la progression du parcours.
|
vacuuming indexes |
VACUUM est en train de nettoyer les index. Si une
table a des index, ceci surviendra au moins une fois par vacuum, après
le parcours complet de la table. Cela pourrait arriver plusieurs fois
par vacuum si maintenance_work_mem (ou, dans
le cas de l'autovacuum, autovacuum_work_mem s'il
est configuré) n'est pas suffisamment important pour y enregistrer le
nombre de lignes mortes trouvées.
|
vacuuming heap |
VACUUM est en train de nettoyer la table. Nettoyer
la table est différent du parcours de la table, et survient après
chaque phase de nettoyage d'index. Si
heap_blks_scanned est inférieur à
heap_blks_total, le système retournera à
parcourir la table après la fin de cette phase. Sinon, il commencera le
nettoyage des index une fois cette phase terminée.
|
cleaning up indexes |
VACUUM est en train de nettoyer les index. Ceci
survient après que la table ait été entièrement parcourue et que le vacuum
des index et de la table soit terminé.
|
truncating heap |
VACUUM est en cours de troncage de la table pour
pouvoir redonner au système d'exploitation les pages vides en fin de
relation. Ceci survient après le nettoyage des index.
|
performing final cleanup |
VACUUM réalise le nettoyage final. Durant cette
phase, VACUUM nettoiera la carte des espaces libres,
mettra à jour les statistiques dans pg_class, et
rapportera les statistiques au collecteur de statistiques. Une fois
cette phase terminée, VACUUM se terminera.
|
Quand CLUSTER ou VACUUM FULL est en
cours d'exécution, la vue pg_stat_progress_cluster
contiendra une ligne pour chaque processus serveur en train d'exécuter une
de ces deux commandes. Les tables ci-dessous décrivent les informations
rapportées et fournissent des informations sur leur interprétation.
Tableau 27.26. Vue pg_stat_progress_cluster
| Colonne | Type | Description |
|---|---|---|
pid | integer | Identifiant du processus serveur. |
datid | oid | OID de la base de données de connexion du processus. |
datname | name | Nom de la base de données de connexion du processus. |
relid | oid | OID de la table en cours de traitement. |
command | text |
La commande exécutée. Soit CLUSTER soit VACUUM FULL.
|
phase | text | Phase de traitement actuelle. Voir Tableau 27.27. |
cluster_index_relid | oid | Si la table est parcourue avec un index, OID de l'index utilisé. Sinon 0. |
heap_tuples_scanned | bigint |
Nombre de lignes parcourues. Ce compteur s'incrémente seulement quand
la phase est
seq scanning heap,
index scanning heap
ou writing new heap.
|
heap_tuples_written | bigint |
Nombre de lignes écrites. Ce compteur s'incrémente seulement quand la
phase est
seq scanning heap,
index scanning heap
ou writing new heap.
|
heap_blks_total | bigint |
Nombre total de blocs dans la table. Ce nombre est rapporté au début de
seq scanning heap.
|
heap_blks_scanned | bigint |
Nombre de blocs parcourus. Ce compteur s'incrément seulement quand la
phase est seq scanning heap.
|
index_rebuild_count | bigint |
Nombre d'index reconstruit. Ce compteur s'incrémente seulement quand la
phase est rebuilding index.
|
Tableau 27.27. Phases de CLUSTER et VACUUM FULL
| Phase | Description |
|---|---|
initializing | La commande prépare le début du parcours de la table. Cette phase est normalement très brève. |
seq scanning heap | La commande parcourt la table en utilisant un parcours séquentiel. |
index scanning heap |
CLUSTER parcourt la table en utilisant un parcours
d'index.
|
sorting tuples |
CLUSTER trie les lignes.
|
writing new heap |
CLUSTER est en cours d'écriture du nouveau fichier
de la table.
|
swapping relation files | La commande bascule les fichiers nouvellement construit en place. |
rebuilding index | La commande reconstruit les index. |
performing final cleanup |
La commande réalise le nettoyage final. Quand cette phase est terminée,
CLUSTER ou VACUUM FULL terminera.
|
