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