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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
