Re: allow changing autovacuum_max_workers without restarting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allow changing autovacuum_max_workers without restarting
Date
Msg-id 1386858.1736220547@sss.pgh.pa.us
Whole thread Raw
In response to Re: allow changing autovacuum_max_workers without restarting  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Mon, Jan 06, 2025 at 06:36:43PM -0500, Tom Lane wrote:
>> We already changed the max_connections default for affected systems
>> as a consequence of 38da05346, so I don't think the argument about not
>> changing it holds much water.

> I see.  Here's a version that uses your max_connections / 8 idea.  I've
> lowered the initial default value of autovacuum_worker_slots to 12 to keep
> the code as simple as possible.  I considered trying 16 in the first
> iteration or constructing a complicated formula like
>     autovacuum_worker_slots = (max_connections * 13) / 75 - 1
> but this stuff is pretty fragile already, so I felt that simplicity was
> desirable in this case.

+1 for simplicity ... but on reflection, what do you think about
using max_connections / 6?  That would keep autovacuum_worker_slots
at 100 / 6 = 16 for the vast majority of systems.  For the worst case
*BSD machines, we'd select 25 / 6 = 4 which results in consuming one
more semaphore than where we were yesterday.  I'm willing to accept
that outcome though, since we still have 3 or so to spare.

Other than the specific magic number, your patch LGTM.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiro Ikeda
Date:
Subject: Re: Doc: fix the rewrite condition when executing ALTER TABLE ADD COLUMN
Next
From: John Naylor
Date:
Subject: Re: Sort functions with specialized comparators