Re: allow changing autovacuum_max_workers without restarting

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: allow changing autovacuum_max_workers without restarting
Дата
Msg-id ZnHZMIJM6rgMVvvM@nathan
обсуждение исходный текст
Ответ на Re: allow changing autovacuum_max_workers without restarting  (Andres Freund <andres@anarazel.de>)
Ответы Re: allow changing autovacuum_max_workers without restarting
Список 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 по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: cost delay brainstorming
Следующее
От: Andres Freund
Дата:
Сообщение: Re: IPC::Run accepts bug reports