Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id 52E90AF3.8010904@dunslane.net
обсуждение исходный текст
Ответ на 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  (Robert Haas <robertmhaas@gmail.com>)
Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 01/29/2014 02:58 AM, Peter Geoghegan wrote:

>
> I am not opposed in principle to adding new things to the counters
> struct in pg_stat_statements. I just think that the fact that the
> overhead of installing the module on a busy production system is
> currently so low is of *major* value, and therefore any person that
> proposes to expand that struct should be required to very conclusively
> demonstrate that there is no appreciably increase in overhead. Having
> a standard deviation column would be nice, but it's still not that
> important. Maybe when we have portable atomic addition we can afford
> to be much more inclusive of that kind of thing.
>


Importance is in the eye of the beholder.  As far as I'm concerned, min 
and max are of FAR less value than stddev. If stddev gets left out I'm 
going to be pretty darned annoyed, especially since the benchmarks seem 
to show the marginal cost as being virtually unmeasurable. If those 
aren't enough for you, perhaps you'd like to state what sort of tests 
would satisfy you.

cheers

andrew






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vik Fearing
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)