PostgreSQLLa base de données la plus sophistiquée au monde.

Version anglaise

27.4. Rapporter la progression

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.

27.4.1. Rapporter la progression du CREATE INDEX

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, « Phases du CREATE INDEX ».
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.

27.4.2. Rapporter la progression du VACUUM

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, « Rapporter la progression de CLUSTER ».

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, « Phases du VACUUM ».
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 if maintenance_work_mem 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 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.

27.4.3. Rapporter la progression de CLUSTER

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, « Phases de CLUSTER et VACUUM FULL ».
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.