That model might make some sense if you think e.g. of a web application,
where the web server has a timeout for how long it waits to get a
database connection from a pool, but once a query is started, the
transaction is considered a succeess no matter how long it takes. The
latency limit would be that timeout. But I think a more useful model is
that when the user clicks a button, he waits at most X seconds for the
result. If that deadline is exceeded, the web server will give a 404, or
the user will simply get bored and go away, and the transaction is
considered a failure.

Correct, the whole TPC-B model better fits an application where client requests enter a queue at the specified TPS rate and that queue is processed.

While we are at it,

Note that in the original TPC-B specification the transaction duration measured is the time from receiving the client request (in current pgbench under throttling that is for when the transaction is scheduled) and when the request is answered. This is the client visible response time, which has nothing to do with the database latency.

Ok. This correspond to the definition used in the current patch. However ISTM that the tpc-b bench is "as fast as possible", there is no underlying schedule as with the throttled pgbench.

As per TPC-B, the entire test is only valid if 90% of all client response times are within 2 seconds.

It would be useful if pgbench would

A) measure and report that client response time in the per transaction
  log files and

I never used the per transaction log file. I think that it may already be the case that it contains this information when not throttled. When under throttling, I do not know.

B) report at the end what percentage of transactions finished within
  a specified response time constraint (default 2 seconds).

What is currently reported is the complement (% of transactions completed over the time limit).

Note that despite pg appaling latency performance, in may stay well over the 90% limit, or even 100%: when things are going well a lot of transaction run in about ms, while when things are going bad transactions would take a long time (although possibly under or about 1s anyway), *but* very few transactions are passed, the throughput is very small. The fact that during 15 seconds only 30 transactions are processed is a detail that does not show up in the metric.


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to