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?)


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.


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!


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to