Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id CAMkU=1wgbyA9AT9TUBmOM29C4nwGnaBm9T6pu_cAkdP05N358A@mail.gmail.com
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
List 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 Flower
<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.

I'm having a hard time imagining how you'd actually implement that.
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 by date:

Previous
From: Gavin Flower
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement
Next
From: Gavin Flower
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement