On 24/10/13 12:24, Peter Geoghegan wrote:
On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes <jeff.ja...@gmail.com> wrote:
The last bucket would be limited to 8ms < x <= 16 ms. If you find something
16ms, then you have to rescale *before* you increment any of the buckets.
Once you do, there is now room to hold it.
How is that laid out in shared memory? If the answer is an array of 32
int64s, one per bucket, -1 from me to this proposal. A huge advantage
of pg_stat_statements today is that the overhead is actually fairly
modest. I really want to preserve that property.
32 int64 buckets is only 256 bytes, so a thousand histograms would be
less than a quarter of a MB. Any machine that busy, would likely have
many GB's of RAM. I have 32 GB on my development machine.
Though, I suppose that the option to have such histograms could be off
by default, which would seem reasonable. How about a convention not to
have histgrams, when the parameter specifying the width of the first
bucket was either missing or set to zero (assuming a 'negative value'
would be a syntax error!).
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
