PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 16.4 » Administration du serveur » Configuration du serveur » Statistiques d'exécution

20.9. Statistiques d'exécution #

20.9.1. Statistiques cumulatives sur les requêtes et index #

Ces paramètres contrôlent le système de statistiques cumulatives. Lorsqu'il est activé, les données récupérées peuvent être visualisées à travers la famille de vues systèmes pg_stat et pg_statio. Consultez Chapitre 28 pour plus d'informations.

track_activities (boolean) #

Active la collecte d'informations sur la commande en cours d'exécution dans chaque session, avec son identifiant et l'heure de démarrage de la commande. Ce paramètre est activé par défaut. Même si le paramètre est activé, cette information est seulement visible aux superutilisateurs, aux rôles ayant les droits du rôle pg_read_all_stats et au rôle propriétaire des sessions tracées (y compris celles appartenant à un rôle dont ils sont membres) ; de ce fait, cela ne représente pas une faille de sécurité. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

track_activity_query_size (integer) #

Indique la quantité de mémoire réservée pour enregistrer le texte de la commande en cours d'exécution pour chaque session active, pour le champ pg_stat_activity.query. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre d'octets. La valeur par défaut est 1024 octets. Ce paramètre peut seulement être configuré au démarrage du serveur.

track_counts (boolean) #

Active la récupération de statistiques sur l'activité de la base de données. Ce paramètre est activé par défaut car le processus autovacuum utilise les informations ainsi récupérées. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

track_io_timing (boolean) #

Active le chronométrage des appels d'entrées/sorties de la base de données. Ce paramètre est désactivé par défaut car il demandera sans cesse l'heure courante au système d'exploitation, ce qui peut causer une surcharge significative sur certaines plateformes. Vous pouvez utiliser l'outil pg_test_timing pour mesurer la surcharge causée par le chronométrage sur votre système. Les informations de chronométrage des entrées/sorties sont affichées dans pg_stat_database, pg_stat_io, dans la sortie de EXPLAIN quand l'option BUFFERS est utilisée, dans la sortie de VACUUM quand l'option VERBOSE est utilisée, par autovacuum pour les auto-vacuums et auto-analyzes quand log_autovacuum_min_duration est configurée, et par pg_stat_statements. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier cette configuration.

track_wal_io_timing (boolean) #

Active le chronométrage des I/O pour les journaux de transactions. Ce paramètre est désactivé par défaut car il implique de nombreux appels supplémentaires au système d'exploitation, ce qui peut être consommateur de ressources pour la plateforme. Vous pouvez utiliser l'outil pg_test_timing pour mesurer la surcharge du chronométrage sur votre système. Les informations de chronométrage des I/O sont disponibles dans la vue pg_stat_wal. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

track_functions (enum) #

Active le suivi du nombre et de la durée des appels aux fonctions. Précisez pl pour ne tracer que les fonctions de langages procéduraux, ou all pour suivre aussi les fonctions SQL et C. La valeur par défaut est none, qui désactive le suivi des statistiques de fonctions. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

Note

Les fonctions en langage SQL qui sont assez simples pour être « inlined », c'est à dire substituées dans le code de la requête appelante, ne seront pas suivies, quelle que soit la valeur de ce paramètre.

stats_fetch_consistency (enum) #

Détermine le comportement quand des statistiques cumulatives sont accédées plusieurs fois dans une transaction. Si configuré à none, chaque accès récupère de nouveau les compteurs à partir de la mémoire partagée. Si configuré à cache, le premier accès aux statistiques pour un objet met en cache ces statistiques jusqu'à la fin de la transaction sauf si pg_stat_clear_snapshot() est appelée. Si configuré à snapshot, le premier accès aux statistiques met en cache toutes les statistiques accessibles pour la base de données de connexion, jusqu'à la fin de la transaction, sauf si pg_stat_clear_snapshot() est appelée. La valeur par défaut est cache.

Note

none est conseillé pour les systèmes de supervision. Si les valeurs ne sont accédées qu'une seule fois, cette configuration est plus efficace. cache assure que des accès répétées rapportent les mêmes valeurs, ce qui est important pour des requêtes impliquant, par exemple;, des jointures sur soi-même. snapshot peut être utile lors d'une inspection itérative des statistiques mais a une surcharge importante, en particulier si beaucoup d'objets existent.

20.9.2. Surveillance et statistiques #

compute_query_id (enum) #

Active le calcul des identifiants de requête. Les identifiants de requête sont disponibles dans la vue pg_stat_activity, en utilisant EXPLAIN, ou dans les traces de PostgreSQL si cela a été configuré avec le paramètre log_line_prefix. L'extension pg_stat_statements nécessite aussi un identifiant de requête. Notez bien qu'un module externe peut être une alternative acceptable pour calculer un identifiant de requête. Dans ce cas, pensez à désactiver le calcul automatique des identifiants de requête par PostgreSQL. Les valeurs acceptées pour ce paramètre sont off (toujours désactivé), on (toujours activé), auto qui permet à des modules externes comme pg_stat_statements de l'activer automatiquement, et regress qui a le même effet que auto, sauf que l'identifiant de requête n'est pas affiché dans la sortie EXPLAIN pour faciliter les tests de régression automatisés. La valeur par défaut est auto.

Note

Pour garantir qu'un seul identifiant de requête soit généré et affiché, les extensions qui génèrent des identifiants de requête doivent lever une erreur si un identifiant de requête a déjà été généré pour une requête.

log_statement_stats (boolean)
log_parser_stats (boolean)
log_planner_stats (boolean)
log_executor_stats (boolean) #

Écrivent, pour chaque requête, les statistiques de performance du module respectif dans les traces du serveur. C'est un outil de profilage très simpliste, similaire aux possibilités de l'appel getrusage() du système d'exploitation Unix. log_statement_stats rapporte les statistiques d'instructions globales, tandis que les autres fournissent un rapport par module. log_statement_stats ne peut pas être activé conjointement à une option de module. Par défaut, toutes ces options sont désactivées. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ces paramètres.