Re: pgbench throttling latency limit

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
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-27 15:08:14
Message-ID: alpine.DEB.2.10.1408271652450.8876@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> As for an actual "latency limit" under throttling, this is significantly
>> more tricky and invasive to implement... ISTM that it would mean:
>> [...]
>
> 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.

If you remove all difficult cases from the spec, it is obviously much
simpler to implement:-) It seems that your simplified version of "latency
limit" would be just to distinguish LATE from ONTIME among the committed
ones, compared to the current version, and not to actually limit the
latency, which is the tricky part.

>> 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.
>
> Ok, fair enough. I don't think doing a "latency limit" would be significantly
> harder, but I can't force you. I'll mark this as Returned with Feedback then.

Hmmm. I can distinguish just the two cases. Rather mark it as "waiting on
author", I may give it a go.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-08-27 15:13:29 Re: pgbench throttling latency limit
Previous Message Robert Haas 2014-08-27 15:04:44 Re: Scaling shared buffer eviction