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 | 5268603D.8050101@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
|
Список | pgsql-hackers |
On 24/10/13 12:24, Peter Geoghegan wrote: > On Wed, Oct 23, 2013 at 4:14 PM, Jeff Janes <jeff.janes@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
В списке pgsql-hackers по дате отправления: