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

From Nathan Bossart
Subject Re: allow changing autovacuum_max_workers without restarting
Date
Msg-id ZnH3dQHtE_k6S2sX@nathan
Whole thread Raw
In response to Re: allow changing autovacuum_max_workers without restarting  (Andres Freund <andres@anarazel.de>)
Responses Re: allow changing autovacuum_max_workers without restarting
List pgsql-hackers
On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> I just don't see much point in reserving 256 worker "possibilities", tbh. I
> can't think of any practical system where it makes sense to use this much (nor
> do I think it's going to be reasonable in the next 10 years) and it's just
> going to waste memory and startup time for everyone.

Given this, here are some options I see for moving this forward:

* lower the cap to, say, 64 or 32
* exclude autovacuum worker slots from computing number of locks, etc.
* make the cap configurable and default it to something low (e.g., 8)

My intent with a reserved set of 256 slots was to prevent users from
needing to deal with two GUCs.  For all practical purposes, it would be
possible to change autovacuum_max_workers whenever you want.  But if the
extra resource requirements are too much of a tax, I'm content to change
course.

-- 
nathan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Next
From: Nathan Bossart
Date:
Subject: Re: cost delay brainstorming