Comprendre les statistiques
Lorsqu’une requête s’exécute, elle doit créer un plan pour décider comment accéder aux données. Par exemple, si une requête SELECT retourne chaque ligne, il n’y a aucun avantage à utiliser un index et il serait plus efficace d’analyser toute la table. Dans ce scénario, il est simple de planifier la requête, mais la plupart des plans de requête ne sont pas si simples à résoudre.
Imaginez un scénario dans lequel vous exécutez une requête qui a recherché chaque commande comprise entre 10,00 $ et 20,00 $. Initialement, nous ne savons pas si la requête retourne toutes les données de la table, ou simplement un petit sous-ensemble. Cette inconnue rend difficile la planification de la stratégie de requête jusqu’à ce que nous voyions les données. Si nous savons que la table contient des commandes qui ont un prix d’achat compris entre 1,00 $ et 800,00 $, un index peut être utilisé pour rechercher un petit sous-ensemble des données. Toutefois, il se peut qu’il n’y ait pas suffisamment d’informations pour générer le plan de requête approprié. Dans cet exemple, bien que les commandes aient un prix d’achat compris entre 1,00 $ et 800,00 $, 95% de commandes sont comprises entre 10,00 $ et 20,00 $ et une analyse des données est en fait le plan le plus efficace.
Avec des scénarios tels que l’exemple précédent, PostgreSQL a besoin de statistiques détaillées pour pouvoir utiliser le plan de requête optimal.
Pour surveiller les statistiques de planification et d’exécution, il existe une extension PostgreSQL appelée pg_stat_statements. pg_stat_statements est activé par défaut dans Azure Database pour PostgreSQL et permet aux membres du rôle pg_read_all_stats d’interroger des statistiques à l’aide de plusieurs vues pg_stat. La requête suivante retourne l’activité de requête à l’aide de la vue pg_stat_activity :
SELECT * FROM pg_stat_activity;
Désactiver pg_stat_statements
Si vos requêtes sont uniques et que vous ne répétez pas régulièrement la même requête, les données de requête historiques sont moins utiles. En outre, si vous n’utilisez pas les vues pg_stat, elles ne fournissent aucun avantage. Il existe une surcharge pour maintenir la pg_stat_statements, qui peut être jusqu’à 50%, et vous pouvez désactiver le suivi des pg_stat_statements dans ces scénarios.
Pour désactiver le suivi de pg_stat_statements, procédez comme suit :
Accédez au portail Azure et sélectionnez votre serveur Azure Database pour PostgreSQL.
Sélectionnez paramètres du serveur et accédez au paramètre pg_stat_statements.track.
Si vous souhaitez désactiver le suivi, sélectionnez NONE.
Pour un suivi plus précis, sélectionnez TOUTES les.
Le paramètre par défaut est TOP.
Sélectionnez Enregistrer.