Re: pgbench throttling latency limit
От | Fabien COELHO |
---|---|
Тема | Re: pgbench throttling latency limit |
Дата | |
Msg-id | alpine.DEB.2.10.1408271652450.8876@sto обсуждение исходный текст |
Ответ на | Re: pgbench throttling latency limit (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: pgbench throttling latency limit
|
Список | 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.
В списке pgsql-hackers по дате отправления: