Re: cost delay brainstorming

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Re: cost delay brainstorming
Дата
Msg-id CAKAnmmJap3OMrmVYQY183cRHSLaSKXZOEeJYUQegpto=_H4qPA@mail.gmail.com
обсуждение исходный текст
Ответ на cost delay brainstorming  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jun 17, 2024 at 3:39 PM Robert Haas <robertmhaas@gmail.com> wrote:
So, a very simple algorithm would be: If the maximum number of workers have been running continuously for more than, say,
10 minutes, assume we're falling behind

Hmm, I don't know about the validity of this. I've seen plenty of cases where we hit the max workers but all is just fine. On the other hand, I don't have an alternative trigger point yet. But I do overall like the idea of dynamically changing the delay. And agree it is pretty conservative.
 
2. If we decided to gradually increase the rate of vacuuming instead of just removing the throttling all at once, what formula would we use
and why would that be the right idea?

Well, since the idea of disabling the delay is on the table, we could raise the cost every minute by X% until we effectively reach an infinite cost / zero delay situation. I presume this would only affect currently running vacs, and future ones would get the default cost until things get triggered again?

Cheers,
Greg

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: may be a buffer overflow problem