From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cost delay brainstorming |
Date: | 2024-06-17 21:44:08 |
Message-ID: | CAKAnmmJap3OMrmVYQY183cRHSLaSKXZOEeJYUQegpto=_H4qPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 17, 2024 at 3:39 PM Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-06-17 21:52:54 | Re: may be a buffer overflow problem |
Previous Message | Andres Freund | 2024-06-17 21:43:05 | Re: Xact end leaves CurrentMemoryContext = TopMemoryContext |