Re: Add min and max execute statement time in pg_stat_statement
От | Andres Freund |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | 20150217151206.GE2895@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
|
Список | pgsql-hackers |
On 2015-02-17 15:50:39 +0100, Petr Jelinek wrote: > On 17/02/15 03:07, Petr Jelinek wrote: > >On 17/02/15 03:03, Andrew Dunstan wrote: > >>On 02/16/2015 08:57 PM, Andrew Dunstan wrote: > >>>>Average of 3 runs of read-only pgbench on my system all with > >>>>pg_stat_statement activated: > >>>>HEAD: 20631 > >>>>SQRT: 20533 > >>>>SQRTD: 20592 > >>>So using sqrtd the cost is 0.18%. I think that's acceptable. > >>Actually, sqrt/sqrtd is not called in accumulating the stats, only in > >>the reporting function. So it looks like the difference here should be > >>noise. Maybe we need some longer runs. > >Yes there are variations between individual runs so it might be really > >just that, I can leave it running for much longer time tomorrow. > Ok so I let it run for more than hour on a different system, the difference > is negligible - 14461 vs 14448 TPS. I think there is bigger difference > between individual runs than between the two versions... These numbers sound like you measured them without concurrency, am I right? If so, the benchmark isn't that interesting - the computation happens while a spinlock is held, and that'll mainly matter if there are many backends running at the same time. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: