Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)

Hello Alvaro,

> Thanks. I didn't look at the code, but while trying to read the docs:
>
>> + <para>
>> + High rate limit schedule lag values, that is values not small with
>> + respect to the actual transaction latency, indicate that something is
>> + amiss in the throttling process.
>
> I couldn't really parse the above. Of the first six words, which one is
> a verb?

None. "High values for the time lag measured with respect to the <rate
limit schedule>".

> Is there a noun that needs to be plural? Is there a word that shouldn't
> be there?

I do not think so.

> ... Oh, I think it makes sense if I assume that "rate limit schedule lag"
> is a single concept .. but if so, that phrase seems too many words for it.
> (So when the RLSL values are high, this indicates a problem. Is that
> what the above means?)

Yep!

> Also, it took me a while to understand what "values not small" means. I
> think there must be a way to phrase this that's easier to understand.

That's what we are trying to do, but we still need to be precise. With
less words it seems more understandable, but previous versions suggested
that the meaning with ambiguous, that is people put their own intuitive
definition of lag, which resulted in surprises at the measures and
cumulative behavior. The alternative was either to change what is
measured, but I insisted that this measure is the useful one, or to try to
reduce the ambiguity of the documentation, the result of efforts by Greg &
myself your helping to debug:-)

>> High lag can highlight a subtle
>> + problem there even if the target rate limit is met in the end.

I'm fine with that, if it is clear from the context that the lag we're
talking about is the one defined on the preceeding paragraph. Greg what
do you think?

>> + One possible cause of schedule lage is insufficient pgbench threads
>> to handle all of the clients.
>
> typo "lage" above.

Indeed.

>> 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. + </para>

Thanks for your help!

--
Fabien.