Re: pgbench throttling latency limit - Mailing list pgsql-hackers

Hello Heikki,

> [...]
> With a latency limit on when the query should finish, as opposed to how 
> late it can start, it's a lot easier to give a number. For example, your 
> requirements might state that a user must always get a response to a click on 
> a web page in 200 ms, so you set the limit to 200 ms.

Yep. See below for the details.

> [...] Why is your patch more interesting than what I described?

It is more interesting because it exists, it is short and simple, it 
works, and it is useful right now to test pg responsiveness and also to 
model some timeout behavior on the client side?

> I'm pretty sure we don't need both.

Why not? Testing performance is tricky enough, the tool must be flexible.

I'm pretty sure that I'm interested in testing pg responsiveness right 
now, so I did the simpler one I need for that purpose. It somehow models 
an application/pooler queue management timeout, that would anyway proceed 
with what is already started.

> [...]
>
> I was thinking that if a query is already late when the connection becomes 
> free to execute it, it would not be executed. It would be skipped, just as in 
> your patch.

As for an actual "latency limit" under throttling, this is significantly 
more tricky and invasive to implement... ISTM that it would mean:
 - if the tx is not stated an the latency is already consummed, SKIP++.
 - if the tx is after its schedule start time but under latency, then   start it, and maybe inject a "SET TIMEOUT...".
 - if a tx is being processed but reaches its latency limit (after   schedule start time), abort it coldly, ROLLBACK++
(wellif the tx is   really started, there could also be shell commands and \set stuff in a   pgbench script, which mean
startedis not really started, so it would   be INTERRUPT++ if no BEGIN was sent).
 
 - if a tx is finished but the final commit returned after the latency   deadline, you cannot abort it anymore but it
islate nevertheless,   LATE++.
 

This is doable but far beyond my current needs. Moreover, I'm not sure 
that such a patch would pass because of invasiveness and complexity, so it 
could be a total loss of time.

> Ok, but *why* are you doing a "lag limit", and not a "latency limit"?

Because it is much simpler (see above) and is enough for testing pg 
responsiveness issue, which is my current objective, and models some
client timeout behavior.

> Under what circumstances is the lag limit a more useful setting?

It is not "more" useful" per se, it is what I'm using to test pg 
unresponsivness with a simple to define and interpret measure wrt 
throttling.

If I would do "latency limit" under throttling, it would be (1) more time 
to develop, more complex, more invasive in the code (see above, + also the 
implementation when not under throttling), (2) more complex to interpret, 
with at least 5 possible outcomes (skipped, interrupted, committed on 
time, committed but late, aborted), (3) this added information would not 
be useful to me.

I've submitted this "simple" lag limit version because being able to 
measure quickly and simply (un)responsiveness seems like a good idea, 
especially given the current state of things.

-- 
Fabien.