Hello Andres,
I noticed that pgbench's -R influences not just the computation of lag, but also of latency. That doesn't look right to me, but maybe I'm just missing something? It's quite easy to demonstrate when running pgbench with/without progress report at a transaction rate that's around the limit of what the server can do: andres@alap4:~/src/postgresql$ pgbench -n -M prepared -c 1 -j 1 -T 100000 -P1 -r -S pgbench_10 progress: 1.0 s, 37416.3 tps, lat 0.027 ms stddev 0.013 progress: 2.0 s, 37345.1 tps, lat 0.027 ms stddev 0.011 progress: 3.0 s, 38787.8 tps, lat 0.026 ms stddev 0.009 ... andres@alap4:~/src/postgresql$ pgbench -n -M prepared -c 1 -j 1 -T 100000 -P1 -r -S -R 37000 pgbench_10 progress: 1.0 s, 32792.8 tps, lat 81.795 ms stddev 35.552, lag 81.765 ms progress: 2.0 s, 37770.6 tps, lat 113.194 ms stddev 4.651, lag 113.168 ms progress: 3.0 s, 37006.3 tps, lat 113.905 ms stddev 5.007, lag 113.878 ms
[...]
Fabien, is this a bug, or am I misunderstanding something?
This behavior under -R is fully voluntary, and the result above just show that the database cannot really keep up with the load, which is simply the case, so for me it is okay to show bad figures.
The idea under throttling is to model a client which would want the result of a query at a certain point in time, say a query for a web page which is being generated, which is the scheduled time. It is the when the client knows it wants an answer. If it is not processed immediately, that is bad for its client perceived latency.
Whether this is due to lag (i.e. the server is loaded and cannot start to process the answer) or because the server is slow to answer is irrelevant, the client is waiting, the web page is not generated, the system is slow. So latency under -R is really "client latency", not only query latency, as it is documented.
You can offset the lag to get the query latency only, but from a client perspective the fact is that the system does not keep up with the scheduled load is the main information, thus this is what is displayed. The bad figures reflect a bad behavior wrt handling the load. For me it is what should be wanted under -R. Maybe it could be more clearly documented, but for me this is the right behavior, and it is I wanted to measure with throttling.
Under this performance model, the client would give up its requests after some time, hence the available --latency-limit option.
-- Fabien.
