Re: pgbench progress report improvements

>>> It is also printed without --rate. There is a "if" above because there is
>>> one report with "lag" (under --rate), and one without.
>> 
>> The code I quoted is for the final report in printResults(), and that only
>> shows latency mean/stddev when using --rate.  The progress reporting in
>> threadRun() does have two variations as you describe.
>
> Indeed, I took it for the progress report. I'll check. It must be consistent 
> whether under --rate or not.

I checked.

The current status is that stddev is currently only available under 
--progress or --rate, and displayed in the final report if --rate.

I can add stddev in the final report *if* progress was on, but not 
otherwise.

This means that under standard benchmarking (no --rate and without 
progress if it is not enabled by default) stddev cannot be shown.

This is consistent with your requirement that gettimeofday calls must be 
avoided, but results in this necessary inconsistency in reporting results.

The alternative is to always measure, but that would imply to always call 
gettimeofday, and I understood that it is a nogo for you. I think that 
your performance concerns are needless:

I confirm a 50,000,000 gettimeofday calls/s on my laptop. On a desktop 
workstation I have 43 millions calls/s. The slowest I have found on an old 
server is 3.3 millions calls/s, that is 0.3 µs per call.

Even so, this is to be compared to the fastest possible transaction 
latency I got which is about 140 µs (one local prepared in-memory table 
select on my laptop), so the overhead 1/450 of the minimum possible 
transaction time, pretty negligeable in my opinion. For transaction times 
which involve disk accesses, the latency is in ms and the overhead well 
under 1/1000.

There are some measures about gettimeofday overhead reported in:
  http://www.atl.external.lmco.com/projects/QoS/POSIX_html/index.html

The worst figure is for a Pentium 166 MHz (!), the overhead is 86.6 µs. 
However typical values are around or under 1 µs, even for old Pentium II 
350 MHz PCs, and this is less that 1% of our minimum possible transaction 
time.

Note also that under option --report-latencies, the number of gettimeofday 
calls is pretty large, and nobody complained.

So I'm of the opinion that we should not worry at all about the number of 
gettimeofday calls in pgbench.

-- 
Fabien.