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++ (well if the tx is
really started, there could also be shell commands and \set stuff in a
pgbench script, which mean started is 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 is late 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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
