Re: Add min and max execute statement time in pg_stat_statement
| От | Jeff Janes |
|---|---|
| Тема | Re: Add min and max execute statement time in pg_stat_statement |
| Дата | |
| Msg-id | CAMkU=1wgbyA9AT9TUBmOM29C4nwGnaBm9T6pu_cAkdP05N358A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Peter Geoghegan <pg@heroku.com>) |
| Список | pgsql-hackers |
On Wed, Oct 23, 2013 at 3:26 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Wed, Oct 23, 2013 at 2:57 PM, Gavin FlowerI'm having a hard time imagining how you'd actually implement that.
<GavinFlower@archidevsys.co.nz> wrote:
> Looks definitely bimodal in the log version, very clear!
>
> Yes, I feel that having a 32 log binary binned histogram (as Alvaro Herrera
> suggested) would be very useful.
For example, this:
https://wiki.postgresql.org/wiki/Aggregate_Histogram
requires that a "limit" be specified ahead of time. Is there a
principled way to increase or decrease this kind of limit over time,
and have the new buckets contents "spill into each other"?
If you are doing a log scale in the bucket widths, 32 buckets covers a huge range, so I think you could get away without having the ability to rescale at all. For example just have the bottom bucket mean <=1ms, and the top bucket mean > 12.42 days (rather than between 12.42 and 24.85 days). But it should be possible to rescale if you really want to. If a bucket >32 is needed, just add bucket[2] into bucket[1], slide buckets 3..32 down one each, and initialize a new bucket 32, and bump the factor that says how many times this shift has been done before.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: