Re: pgbench progress report improvements - split 3 v2 - A

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, pavel(dot)stehule(at)gmail(dot)com
Subject: Re: pgbench progress report improvements - split 3 v2 - A
Date: 2013-09-26 18:50:15
Message-ID: alpine.DEB.2.02.1309262046020.5704@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> Patch (4): Redefine "latency" as reported by pgbench and report "lag" more.

Here is a first partial patch, which focusses on measuring latency and
reporting the measure under --progress.


Improve pgbench measurements & progress report

Measure transaction latency instead under --rate and --progress.

The previous computed figure does not make sense under throttling:
as sleep throttling time was included in the figures, the displayed
results were plain false.

The latency and its standard deviation are printed out under progress and
in the final report when available.

It could be made "always" available, but that would require to accept
additional gettimeofday calls. I do not think that there is a performance
issue here, but there is significant opposition to the idea.

Sample output under benchmarking with --progress=1

progress: 1.0 s, 2626.1 tps, 0.374 stddev 0.597 ms lat
progress: 2.0 s, 2766.6 tps, 0.358 stddev 0.588 ms lat
progress: 3.0 s, 2567.4 tps, 0.385 stddev 0.665 ms lat
progress: 4.0 s, 3014.2 tps, 0.328 stddev 0.593 ms lat
progress: 5.0 s, 2959.3 tps, 0.334 stddev 0.553 ms lat
progress: 16.0 s, 5009.2 tps, 0.197 stddev 0.381 ms lat
progress: 24.0 s, 7051.2 tps, 0.139 stddev 0.284 ms lat
progress: 50.0 s, 6860.5 tps, 0.143 stddev 0.052 ms lat

The "warmup" is quite fast because the DB is on a SSD. In the beginning
the standard deviation is well over the average transaction time, but
when the steady state is reached (later) it is much below.


Attachment Content-Type Size
pgbench-measurements-v5-A.patch text/x-diff 9.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2013-09-26 18:58:45 Re: Minmax indexes
Previous Message Steve Singer 2013-09-26 18:47:55 Re: logical changeset generation v6