Re: cost delay brainstorming - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: cost delay brainstorming
Date
Msg-id CAKAnmmJap3OMrmVYQY183cRHSLaSKXZOEeJYUQegpto=_H4qPA@mail.gmail.com
Whole thread Raw
In response to cost delay brainstorming  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Next
From: Daniel Gustafsson
Date:
Subject: Re: may be a buffer overflow problem