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
|
Список | 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 по дате отправления: