From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Rukh Meski <rukh(dot)meski(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench throttling latency limit |
Date: | 2014-08-29 09:56:50 |
Message-ID: | 54004E62.1000002@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/27/2014 08:05 PM, Fabien COELHO wrote:
>
>>> [...]
>>
>> Yeah, something like that. I don't think it would be necessary to set
>> statement_timeout, you can inject that in your script or postgresql.conf if
>> you want. I don't think aborting a transaction that's already started is
>> necessary either. You could count it as LATE, but let it finish first.
>
> I've implemented something along these simplified lines. The latency is
> not limited as such, but slow (over the limit) queries are counted and
> reported.
Ok, thanks.
This now begs the question:
In --rate mode, shouldn't the reported transaction latency also be
calculated from the *scheduled* start time, not the time the transaction
actually started? Otherwise we're using two different definitions of
"latency", one for the purpose of the limit, and another for reporting.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2014-08-29 10:20:31 | Re: LIMIT for UPDATE and DELETE |
Previous Message | Heikki Linnakangas | 2014-08-29 09:38:48 | Re: v4 protocol TODO item - Lazy fetch/stream of TOASTed values? |