Date: Thu, 2 May 2024 20:04:15 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: "Imseih (AWS), Sami" <simseih@amazon.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allow changing autovacuum_max_workers without restarting
Message-ID: <20240503010415.GA1008894@nathanxps13>
References: <20240410212344.GA1824549@nathanxps13>
 <Zh0srZSCSfcK_oY9@pryzbyj2023>
 <20240415162833.GA2857238@nathanxps13>
 <20240415163749.GA2858464@nathanxps13>
 <96B4FC7B-A919-4F93-80A3-BA3EA4F8479A@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <96B4FC7B-A919-4F93-80A3-BA3EA4F8479A@amazon.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20240503010415.GA1008894%40nathanxps13>
Precedence: bulk

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