Re: Cost limited statements RFC

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Cost limited statements RFC
Дата
Msg-id CAMkU=1zK2RU8E_EWMfREw2YGi1TTB0e5g_1xSVv1jz=k7MdG5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cost limited statements RFC  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Cost limited statements RFC  (Greg Smith <greg@2ndQuadrant.com>)
Re: Cost limited statements RFC  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers



On Thu, Jun 6, 2013 at 1:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:

If we can see our way clear to ripping out the autovacuum costing
stuff and replacing them with a read rate limit and a dirty rate
limit, I'd be in favor of that.  The current system limits the linear
combination of those with user-specified coefficients, which is more
powerful but less intuitive.  If we need that, we'll have to keep it
the way it is, but I'm hoping we don't.


I don't know what two independent setting would look like.  Say you keep two independent counters, where each can trigger a sleep, and the triggering of that sleep clears only its own counter.  Now you still have a limit on the linear combination, it is just that summation has moved to a different location.  You have two independent streams of sleeps, but they add up to the same amount of sleeping as a single stream based on a summed counter.

Or if one sleep clears both counters (the one that triggered it and the other one), I don't think that that is what I would call independent either.  Or at least not if it has no memory.  The intuitive meaning of independent would require that it keep track of which of the two counters was "controlling" over the last few seconds.  Am I overthinking this?

Also, in all the anecdotes I've been hearing about autovacuum causing problems from too much IO, in which people can identify the specific problem, it has always been the write pressure, not the read, that caused the problem.  Should the default be to have the read limit be inactive and rely on the dirty-limit to do the throttling?
 
Cheers,

Jeff

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Optimising Foreign Key checks
Следующее
От: Simon Riggs
Дата:
Сообщение: ALTER TABLE ... ALTER CONSTRAINT