Re: Add min and max execute statement time in pg_stat_statement
От | Petr Jelinek |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | 54E3608E.4090009@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On 17/02/15 16:12, Andres Freund wrote: > 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. > It's pgbench -j16 -c32 -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: