RE: Adding percentile metrics to pg_stat_statements module

From: benoit <benoit(at)hopsandfork(dot)com>
To: Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Igor Calabria <igor(dot)calabria(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Adding percentile metrics to pg_stat_statements module
Date: 2023-06-05 08:05:10
Message-ID: 4c77f9cfb35149b5a245c8a7ef6923f0@hopsandfork.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

While looking at slow queries on pg_stat_statements. I was looking for percentile fields..

If we are worried about CPU cost, maybe it could be useful to turn in on when you have a high stddev_exec_time for the query ?

Regards,

________________________________
De : Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>
Envoyé : samedi 2 novembre 2019 10:23:49
À : Tomas Vondra; Igor Calabria
Cc : pgsql-hackers(at)postgresql(dot)org
Objet : Re: Adding percentile metrics to pg_stat_statements module

On 10/31/19 8:32 PM, Tomas Vondra wrote:
> IMO having some sort of CDF approximation (being a q-digest or t-digest)
> would be useful, although it'd probably need to be optional (mostly
> becuase of memory consumption).

+1, I like this idea. If we are afraid of CPU cost we could imagine some kind of
sampling or add the possibility to collect only for a specific queryid.

I dreamed of this kind of feature for PoWA. Thus, it could make possible to
compare CDF between two days for example, before and after introducing a change.

Regards,

--
Adrien NAYRAT

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2023-06-05 08:05:26 Re: pgbench - adding pl/pgsql versions of tests
Previous Message Laurenz Albe 2023-06-05 07:32:33 Re: Mark a transaction uncommittable