Re: Add min and max execute statement time in pg_stat_statement
От | Gavin Flower |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | 526854FB.8080302@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
Re: Add min and max execute statement time in pg_stat_statement |
Список | pgsql-hackers |
On 24/10/13 11:26, Peter Geoghegan 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"? > To smplify things, I'm using 5 buckets, but 32 would be better. Assume first bucket width is 1ms. bucket range 0 x =< 1ms 1 1ms < x =< 2ms 2 2ms < x =< 4ms 3 4ms < x =< 8ms 5 8ms < x If the size of the first bucket changed, then implicitly the histogram would be restarted. As there is no meaningful way of using any data from the existing histogram - even if the size of the first bucket was a power of 2 greater than the old one (here things are fine, until you try and apportion the data in the last bucket!). Cheers, Gavin
В списке pgsql-hackers по дате отправления: