PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 13.0 » Administration du serveur » Surveiller l'activité de la base de données » Rapporter la progression

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 ANALYZE, CLUSTER, CREATE INDEX, VACUUM, and BASE_BACKUP (i.e., commande de réplication que pg_basebackup exécute pour réaliser une sauvegarde de base). Ceci pourrait être étendu dans le futur.

27.4.1. Rapporter la progression d'ANALYZE

Quand ANALYZE est en cours d'exécution, la vue pg_stat_progress_analyze contiendra une ligne pour chaque processus qui exécute actuellement cette commande. Les tables ci-dessous décrivent les informations rapportées et fournissent des informations sur leur interprétation.

Tableau 27.32. Vue pg_stat_progress_analyze

Type

Description

pid integer

Identifiant du processus serveur.

datid oid

OID de la base de données où ce processus est connecté.

datname name

Nom de la base de données où ce processus est connecté.

relid oid

OID de la table en cours de traitement par ANALYZE.

phase text

Phase de traitement courante. Voir Tableau 27.33.

sample_blks_total bigint

Nombre total de blocs de la table à traiter.

sample_blks_scanned bigint

Nombre de blocs parcourus.

ext_stats_total bigint

Nombre de statistiques étendues.

ext_stats_computed bigint

Nombre de statistiques étendues calculées. Ce compteur avance seulement quand la phase est computing extended statistics.

child_tables_total bigint

Nombre de tables enfants.

child_tables_done bigint

Nombre de tables enfants parcourues. Ce compteur avance seulement quand la phase est acquiring inherited sample rows.

current_child_table_relid oid

OID de la table enfant en cours de traitement. Ce champ est seulement valide quand la phase est acquiring inherited sample rows.


Tableau 27.33. Phases ANALYZE

PhaseDescription
initializing La commande prépare le début du traitement de la table. Cette phase est normalement très brève.
acquiring sample rows La command est en cours de parcours de la table indiquée par relid pour obtenir les lignes de l'échantillon.
acquiring inherited sample rows La command est en cours de parcours des tables enfants pour obtenir les lignes de l'échantillon. Les colonnes child_tables_total, child_tables_done et current_child_table_relid contiennent les informations de progression pour cette phase.
computing statistics La command calcule les statistiques à partir des lignes de l'échantillon obtenu lors du parcours de la table.
computing extended statistics La commande calcule les statistiques étendues à partir des lignes de l'échantillon obtenu lors du parcours de la table.
finalizing analyze La commande met à jour pg_class. Quand cette phase est terminée, ANALYZE terminera.

Note

Notez que quand ANALYZE est exécutée sur une table partitionnée,toutes ces partitions sont traitées récursivement comme mentionnées dans ANALYZE. Dans ce cas, la progression d'ANALYZE est rapportée tout d'abord pour la table parent alors que les statistiques d'héritage sont récupérées, suivies par celles de chaque partition.

27.4.2. 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.34. Vue pg_stat_progress_create_index

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.35.

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.35. Phases du CREATE INDEX

PhaseDescription
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.3. 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.4.

Tableau 27.36. Vue pg_stat_progress_vacuum

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.37.

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.37. Phases du VACUUM

PhaseDescription
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.4. 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.38. Vue pg_stat_progress_cluster

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.39.

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.39. Phases de CLUSTER et VACUUM FULL

PhaseDescription
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.

27.4.5. Rapporter la progression de la sauvegarde de base

Quand une application comme pg_basebackup réalise une sauvegarde de base, la vue pg_stat_progress_basebackup contiendra une ligne pour chaque processus walsender en cours d'exécution de la commande de réplication BASE_BACKUP et d'envoi de la sauvegarde. Les tables ci-dessous décrivent les informations qui seront rapportées et fournissent des informations sur leur interprétation.

Tableau 27.40. Vue pg_stat_progress_basebackup

Type

Description

pid integer

Identifiant du processus walsender.

phase text

Phase en cours de traitement. Voir Tableau 27.41.

backup_total bigint

Quantité totale de données à envoyer. Ceci est estimé et rapporté au début de la phase streaming database files. Notez que c'est uniquement une approximation car la base de données pourrait changer pendant la phase streaming database files et les journaux de transactions pourraient être inclus dans la sauvegarde après coup. C'est toujours la même valeur que backup_streamed une fois la quantité de données envoyées dépasse la taille totale estimée. Si l'estimation est désactivée dans total size. If the estimation is disabled in pg_basebackup (grâce à l'option --no-estimate-size), cette colonne vaut NULL.

backup_streamed bigint

Quantité de données envoyées. Ce compteur avance seulement quand la phase est streaming database files ou transferring wal files.

tablespaces_total bigint

Nombre total de tablespaces à envoyer.

tablespaces_streamed bigint

Nombre de tablespaces envoyées. Ce compteur avance seulement quand la phase est streaming database files.


Tableau 27.41. Phases de la sauvegarde de base

PhaseDescription
initializing Le processus walsender prépare le début de la sauvegarde. Cette phase est normalement très brève.
waiting for checkpoint to finish Le processus walsender est en cours d'exécution de pg_start_backup pour initialiser une sauvegarde de base, et en attente que le checkpoint de début de sauvegarde se finisse.
estimating backup size Le processus walsender estime actuellement la quantité totale des fichiers de la base à envoyer comme une sauvegarde de base.
streaming database files Le processus walsender est en cours d'envoi les fichiers de la base comme sauvegarde de base.
waiting for wal archiving to finish Le processus walsender exécute actuellement le pg_stop_backup pour terminer la sauvegarde, et est en attente de tous les journaux de transactions requis pour que la sauvegarde de base soit correctement archivée. Si l'option --wal-method=none ou l'option --wal-method=stream est spécifié avec pg_basebackup, la sauvegarde se terminera une fois cette phase terminée.
transferring wal files Le processus walsender est en cours de transfert des journaux de transactions générés lors de la sauvegarde. Cette phase survient après la phase waiting for wal archiving to finish si l'option --wal-method=fetch est indiquée à pg_basebackup. La sauvegarde se terminera quand cette phase sera terminée.