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  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Add min and max execute statement time in pg_stat_statement
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Add min and max execute statement time in pg_stat_statement