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 20240503010415.GA1008894@nathanxps13
Whole thread Raw
In response to Re: allow changing autovacuum_max_workers without restarting  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Responses Re: allow changing autovacuum_max_workers without restarting
List pgsql-hackers
On Mon, Apr 15, 2024 at 05:41:04PM +0000, Imseih (AWS), Sami wrote:
>> Another option could be to just remove the restart-only GUC and hard-code
>> the upper limit of autovacuum_max_workers to 64 or 128 or something. While
>> that would simplify matters, I suspect it would be hard to choose an
>> appropriate limit that won't quickly become outdated.
> 
> Hardcoded values are usually hard to deal with because they are hidden either
> In code or in docs.

That's true, but using a hard-coded limit means we no longer need to add a
new GUC.  Always allocating, say, 256 slots might require a few additional
kilobytes of shared memory, most of which will go unused, but that seems
unlikely to be a problem for the systems that will run Postgres v18.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Weird "null" errors during DROP TYPE (pg_upgrade)
Next
From: Nathan Bossart
Date:
Subject: improve performance of pg_dump with many sequences