Re: Patch to show individual statement latencies in pgbench output

Greg Smith <greg@2ndquadrant.com>

From: Greg Smith <greg@2ndquadrant.com>
To: Florian Pflug <fgp@phlo.org>
Cc: PostgreSQL-development hackers <pgsql-hackers@postgresql.org>
Date: 2010-08-11T04:34:05Z
Lists: pgsql-hackers

Attachments

Florian Pflug wrote:
> Attached is an updated version (v4).
>   

I've attached a v5.  No real code changes from Florian's version, just 
some wording/style fixes and rework on the documentation.  The user side 
is now consistent about calling these statement latencies for example, 
even though the internals still call them command latencies most places.

Since using this new feature will introduce a whole stack of new calls 
to get the system time, I also added a warning about that impacting results:

    Note that collecting the additional timing information needed for
    detailed latency computation does add some overhead.  This will slow
    average execution speed and lower the computed TPS.  The exact amount
    of slowdown varies significantly based on platform and hardware.
    Comparing average TPS values with and without latency reporting enabled
    is a good way to measure if the timing overhead is significant.

I wasn't able to see any significant slowdown on my modern Linux systems 
doing such a test:

$ ./pgbench -T 10 -S -c 8 -j 4 pgbench
tps = 6716.039813 (including connections establishing)
tps = 6720.238878 (excluding connections establishing)
$ ./pgbench -T 10 -S -c 8 -j 4 -r pgbench
tps = 6708.544618 (including connections establishing)
tps = 6712.728526 (excluding connections establishing)

But I know gettimeofday is fast here.  Worth including a warning for 
though I think.

I'm out of things to check here, marking this one ready for a committer 
review.  The patch hasn't had a committer assigned yet, so whoever wants 
to claim it should mark the CF app.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us