Passer au contenu principal
Query Insights recueille la télémétrie de chaque instruction de votre instance Managed Postgres et classe chaque pattern de requête par impact, afin de vous permettre de passer de “le p99 dérive à la hausse” à “ce pattern écrit sur disque” sans quitter la console Cloud. Les données proviennent de pg_stat_ch, l’extension Postgres open-source qui transmet en flux des compteurs par instruction vers ClickHouse Cloud. La télémétrie est normalisée dans Postgres avant de quitter la base de données — les littéraux sont supprimés et remplacés par des placeholders, afin que les valeurs exactes utilisées dans vos requêtes n’entrent jamais dans le flux de télémétrie.

​
Ouvrir Query insights

Ouvrez votre instance Managed Postgres dans la Cloud Console, puis cliquez sur Query insights dans la barre latérale gauche. La page se divise en quatre zones, dans l’ordre où vous les utiliserez réellement :
  • Un vue d’ensemble qui affiche sur un seul écran un aperçu de l’état de santé de la base de données.
  • Une table requête lente récurrente qui classe chaque query pattern exécuté par votre base de données, triée selon le critère qui vous semble pertinent.
  • Un panneau requête récente qui répertorie les exécutions individuelles dans l’ordre chronologique inverse.
  • Un volet de détail qui agrège tous les compteurs pour un seul pattern.
Utilisez le sélecteur Time period en haut pour basculer entre les 15 dernières minutes, la dernière heure, le dernier jour, la dernière semaine ou le dernier mois. La taille des buckets d’agrégation s’ajuste automatiquement : buckets d’1 minute pour les 15 dernières minutes ou la dernière heure, de 5 minutes pour le dernier jour, et d’1 heure pour la dernière semaine ou le dernier mois, afin que les charts restent réactifs.

​
Vue d’ensemble

La vue d’ensemble se présente sous la forme d’une grille 3×2 de six panneaux : Un seul écran vous permet de voir si la base de données est saine. Une instance saine présente un profil familier : un taux de succès du buffer proche de 100 %, un volume de requêtes qui suit le trafic applicatif, un taux d’erreur stable ou nul, et des latences par percentile qui restent proches les unes des autres.

​
Requêtes lentes récurrentes

Lorsque la vue d’ensemble signale un problème, c’est dans ce tableau que l’analyse commence. Une ligne par pattern de requête normalisé, avec les littéraux supprimés pour que les exécutions d’une même instruction SQL se regroupent sur une seule et même ligne.

​
Trier selon ce que vous soupçonnez

Le tableau est trié par défaut par Durée d’exécution totale par ordre décroissant — de cette façon, le pattern en tête est généralement la réponse à « qu’est-ce qui me coûte le plus ? » Il ne s’agit pas forcément du pattern le plus lent pris individuellement. Une requête exécutée huit millions de fois par jour en douze millisecondes peut compter davantage que celle qui ne s’est exécutée qu’une seule fois en trois secondes. Chaque tri vous donne un angle de vue différent :
  • Durée d’exécution totale — là où la base de données a passé le plus de temps réel.
  • Temps CPU — patterns gourmands en calcul.
  • Appels — patterns très fréquents.
  • Erreurs — échecs répétés.
  • Latence moy / P50 / P95 / P99 / max — valeurs aberrantes, par percentile.
  • Lignes renvoyées, Blocs lus, Blocs en cache, Octets WAL — patterns qui ont fait transiter le plus de données via le moteur, le cache ou le journal de transactions.
Cliquez sur le bouton Colonnes pour afficher ou masquer des colonnes supplémentaires. Le tableau des patterns expose 19 colonnes au total, y compris la ventilation par percentile, le taux de réussite du cache et le temps CPU par pattern.

​
Affiner la table

Filtrez la table en fonction de la partie de votre charge de travail que vous êtes en train d’analyser :
  • Base de données
  • Utilisateur
  • Opération (SELECT, INSERT, UPDATE, DELETE, …)
  • Application — le application_name de la chaîne de connexion
« Montre-moi uniquement ce que fait le service orders sur la base de données sales » se traduit par deux menus déroulants. Les valeurs de filtre se renseignent automatiquement à partir de ce que votre instance a réellement exécuté.

​
Requêtes récentes

Sous le tableau des patterns, le panneau requête récente liste les exécutions individuelles dans l’ordre chronologique inverse — une ligne par instruction exécutée, et non une ligne par pattern. Utilisez-le lorsque vous voulez le flux brut d’événements plutôt qu’un agrégat, par exemple pour vérifier rapidement qu’un correctif a bien été pris en compte ou pour trouver le moment exact où une erreur s’est produite. Les colonnes par défaut sont Time, Operation, Query, Duration, Rows, Database, User et Blks read. Ouvrez le sélecteur Columns pour afficher Application, Blks hit, CPU user, CPU sys et PID. Le tableau accepte les mêmes filtres Database, User, Operation et Application que le tableau des patterns, et peut être trié par Time, Duration, Rows, Blks read et CPU time. Cliquez sur n’importe quelle ligne pour ouvrir le même volet de détails que le tableau des patterns, ciblé sur le pattern de cette exécution précise.

​
Volet de détail

Cliquez sur n’importe quelle ligne du tableau des patterns ou des requêtes récentes pour ouvrir à droite le volet Détail de la requête. Ce volet regroupe toutes les exécutions de ce pattern sur l’intervalle de temps sélectionné et agrège les compteurs qui expliquent pourquoi il est lent. Le volet se présente sous la forme d’une vue unique à défilement comportant cinq sections :
  • Modèle de requête — le SQL normalisé avec les littéraux remplacés par $1, $2, … et un bouton pour copier dans le presse-papiers.
  • Utilisation agrégée des ressources — une grille de 13 cartes de statistiques couvrant le nombre total d’appels, la latence moy/P95/P99/max, le temps d’exécution total, les lignes renvoyées, le ratio de succès du cache, les blocs lus, les blocs touchés, le temps CPU, les octets WAL et les erreurs.
  • Contexte de la requête — la base de données, l’utilisateur, l’opération et l’application dont provient ce pattern.
  • Exécutions notables — les erreurs, les exécutions inhabituellement lentes et celles qui renvoient de gros volumes de résultats, affichées avant la liste complète des exécutions récentes.
  • Exécutions récentes — les exécutions individuelles du même pattern, avec des compteurs par exécution.

​
Compteurs par exécution

Développez une exécution récente pour afficher les compteurs qui indiquent précisément où le temps a été consacré :
  • Blocs partagés — lectures et hits toujours affichés ; écritures et blocs salis affichés lorsqu’ils sont non nuls.
  • Opérations sur blocs locaux et temporaires — des opérations sur blocs temporaires non nulles signifient qu’un tri ou un hachage a débordé sur disque.
  • Temps de lecture / écriture — temps d’E/S, distinct du temps CPU.
  • Temps CPU — utilisateur et système, séparément.
  • Workers parallèles — prévus vs. réellement lancés.
  • JIT — temps total de compilation JIT et nombre de fonctions.
  • WAL — octets et nombre d’enregistrements.
Tout ce dont vous avez besoin pour diagnostiquer un problème de lenteur se trouve au même endroit, sur un seul écran.

​
API Query insights

La même télémétrie est également disponible via ClickHouse Cloud OpenAPI. La table requête lente récurrente correspond à l’endpoint lister les patterns de requêtes lentes, et le volet de détail correspond à l’endpoint récupérer un pattern de requête lente, qui renvoie les métriques agrégées d’un pattern ainsi que ses exécutions récentes.

​
Fonctionnement

​
Normalisée dans Postgres, avant le wire

pg_stat_ch intercepte la phase parse-analyze, remplace chaque littéral par un espace réservé ($1, $2, …) et met en cache le pattern obtenu dans un cache LRU propre à chaque backend, indexé par queryid. Lorsque l’executor termine l’instruction, c’est ce pattern mis en cache qui est associé à l’événement. L’instruction exacte avec ses valeurs ne quitte jamais la base de données.

​
Sans impacter la base de données

Le producteur ajoute environ 3 % de surcharge par instruction. Le chemin de mise en file d’attente utilise un try-lock non bloquant sur un tampon circulaire en mémoire partagée. En cas de forte charge, l’extension supprime les événements en incrémentant un compteur plutôt que de ralentir Postgres.

​
Événements bruts, non agrégés

pg_stat_ch émet un événement brut par instruction exécutée (principale ou imbriquée), selon l’échantillonnage appliqué. Chaque percentile, classement et ventilation dans l’UI correspond à une requête ClickHouse exécutée sur ce même flux d’événements.

​
Le même moteur que celui de nos clients

Le backend d’Insights, c’est ClickHouse Cloud. La télémétrie par requête d’une instance Postgres très sollicitée représente des millions de lignes par jour ; la compression colonnaire permet de conserver à faible coût des mois de détails par exécution, et des agrégations en moins d’une seconde sur des milliards de lignes maintiennent l’UI réactive lorsque vous explorez les données sur une semaine ou un mois.

​
Open source

pg_stat_ch est sous licence Apache 2.0. Utilisez-le avec n’importe quel Postgres et envoyez les données vers n’importe quel ClickHouse. Le code source et les tickets sont disponibles sur github.com/clickhouse/pg_stat_ch.
Dernière modification le 2 juillet 2026