>>> 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.
