Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id 54E3608E.4090009@2ndquadrant.com
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Auditing extension for PostgreSQL (Take 2)
Next
From: Robert Haas
Date:
Subject: Re: Add pg_settings.pending_restart column