Re: cost delay brainstorming

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

In response to

Browse pgsql-hackers by date

  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