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 52E9736E.8010500@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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 01/29/2014 04:14 PM, Peter Geoghegan wrote:
> On Wed, Jan 29, 2014 at 6:06 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> mportance 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.
> I certainly agree that stddev is far more valuable than min and max.
> I'd be inclined to not accept the latter on the grounds that they
> aren't that useful.
>
> So, am I correct in my understanding: The benchmark performed here [1]
> was of a standard pgbench SELECT workload, with no other factor
> influencing the general overhead (unlike the later test that queried
> pg_stat_statements as well)? I'd prefer to have seen the impact on a
> 32 core system, where spinlock contention would naturally be more
> likely to appear, but even still I'm duly satisfied.

I could live with just stddev. Not sure others would be so happy.

Glad we're good on the performance impact front.

cheers

andrew




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

Предыдущее
От: Andreas Karlsson
Дата:
Сообщение: Re: Planning time in explain/explain analyze
Следующее
От: Pavel Stehule
Дата:
Сообщение: tests for client programs