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 20240507160605.GA2523153@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 Fri, May 03, 2024 at 12:57:18PM +0000, Imseih (AWS), Sami wrote:
>> 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.
> 
> I agree with this.

Here's what this might look like.  I chose an upper limit of 1024, which
seems like it "ought to be enough for anybody," at least for now.

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

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: PERIOD foreign key feature
Next
From: Paul Jungwirth
Date:
Subject: Re: PERIOD foreign key feature