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 |
Дата | |
Msg-id | CAM3SWZQzZxMgLDOGQxTH+YMrwLo9bC96=gfvuMV3an5M7zwZNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
|
Список | pgsql-hackers |
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. There was no testing of the performance impact prior to 6 days ago, and I'm surprised it took Mitsumasa that long to come up with something like this, since I raised this concern about 3 months ago. [1] http://www.postgresql.org/message-id/52E10E6A.5060708@lab.ntt.co.jp -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: