Hello Heikki,
>> I think we have to reconsider what we're reporting in 9.4, when --rate
>> is enabled, even though it's already very late in the release cycle.
>> It's a bad idea to change the definition of latency between 9.4 and 9.5,
>> so let's get it right in 9.4.
Indeed.
> As per the attached patch. I think we should commit this to 9.4. Any
> objections?
Ok for me. Some more propositions about the doc below.
> The text this patch adds to the documentation needs some rewording, though.
Probably. Not sure how to improve.
> As does this existing paragraph:
>
>> High rate limit schedule lag values, that is lag values that are
>> large compared to the actual transaction latency, indicate that
>> something is amiss in the throttling process. High schedule lag can
>> highlight a subtle problem there even if the target rate limit is met
>> in the end.
>> One possible cause of schedule lag is insufficient
>> pgbench threads to handle all of the clients. To improve that,
>> consider reducing the number of clients, increasing the number of
>> threads in pgbench, or running pgbench on a separate host. Another
>> possibility is that the database is not keeping up with the load at
>> some point. When that happens, you will have to reduce the expected
>> transaction rate to lower schedule lag.
>
> It took me ages to parse "high rate limit schedule lag values".
Indeed, I'm not proud of that one... Moreover the first sentence becomes
false with the new latency computation, as the lag time is included.
I would suggest:
"When under throttling, the reported lag time measures the delay between
the scheduled start time for the transaction and its actual start time. A
high value, where the lag time represent most of the transaction latency,
may indicate that something is amiss in the throttling process itself,
even if the target rate is met in the end. One possible cause ..."
--
Fabien.
