On 24/10/13 12:00, Gavin Flower wrote:
On 24/10/13 11:26, Peter Geoghegan wrote:
On Wed, Oct 23, 2013 at 2:57 PM, Gavin Flower
<gavinflo...@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
Arghhhhh!
Just realized, that even if the size of the first bucket was a power of
2 greater than the old one, then you can't meaningfully use any of the
old data in any of the old buckets (this is 'obvious; but somewhat messy
to explain!)
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
