On 08/27/2014 03:47 AM, Rukh Meski wrote:
Hi Fabien,
On Tue, Aug 26, 2014 at 04:07 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
Please find attached a new version which fixes these two points.
Indeed it does. Marking the patch ready for a committer.
I find the definition of the latency limit a bit strange. It's a limit
on how late a transaction can *start* compared to it's scheduled
starting time, not how long a query is allowed to last. How do figure
out what it should be set to?
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.
So I think a more useful model is that new queries arrive at a given
rate, and each query is expected to finish in X milliseconds from its
arrival time (i.e the time the query is scheduled to begin, not the time
it was sent to the server) or it's counted as failed. If a transaction
cannot even be started by that deadline, because the connection is still
busy with the previous query, it's counted as failed without even
sending it to the server.
With that definition, it makes sense to specify the latency limit even
without --rate. In that case, it's simply a limit on how long each
query's execution is allowed to last until it's considered as failed.
IOW, each query's scheduled start time is when the previous query ends.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
