|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
|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|