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 ZnHZMIJM6rgMVvvM@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 Mon, Jun 03, 2024 at 04:24:27PM -0700, Andres Freund wrote:
> On 2024-06-03 14:28:13 -0500, Nathan Bossart wrote:
>> On Mon, Jun 03, 2024 at 12:08:52PM -0700, Andres Freund wrote:
>> > Why do we think that increasing the number of PGPROC slots, heavyweight locks
>> > etc by 256 isn't going to cause issues?  That's not an insubstantial amount of
>> > memory to dedicate to something that will practically never be used.
>> 
>> I personally have not observed problems with these kinds of bumps in
>> resource usage, although I may be biased towards larger systems where it
>> doesn't matter as much.
> 
> IME it matters *more* on larger systems. Or at least used to, I haven't
> experimented with this in quite a while.
> 
> It's possible that we improved a bunch of things sufficiently for this to not
> matter anymore.

I'm curious if there is something specific you would look into to verify
this.  IIUC one concern is the lock table not fitting into L3.  Is there
anything else?  Any particular workloads you have in mind?

-- 
nathan



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: cost delay brainstorming
Next
From: Andres Freund
Date:
Subject: Re: IPC::Run accepts bug reports