Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id CA+TgmoYOG-aJUPBWPxzMuHEEW+RbHgL0zJzNT7mh06hk43eopw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add min and max execute statement time in pg_stat_statement  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Wed, Jan 29, 2014 at 9:06 AM, Andrew Dunstan <andrew@dunslane.net> 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.

I agree.  I find it somewhat unlikely that pg_stat_statements is
fragile enough that these few extra counters are going to make much of
a difference.  At the same time, I find min and max a dubious value
proposition.  It seems highly likely to me that stddev will pay its
way, but I'm much less certain about the others.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Christian Kruse
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)