From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allow changing autovacuum_max_workers without restarting |
Date: | 2024-06-18 21:09:09 |
Message-ID: | ZnH3dQHtE_k6S2sX@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote:
> I just don't see much point in reserving 256 worker "possibilities", tbh. I
> can't think of any practical system where it makes sense to use this much (nor
> do I think it's going to be reasonable in the next 10 years) and it's just
> going to waste memory and startup time for everyone.
Given this, here are some options I see for moving this forward:
* lower the cap to, say, 64 or 32
* exclude autovacuum worker slots from computing number of locks, etc.
* make the cap configurable and default it to something low (e.g., 8)
My intent with a reserved set of 256 slots was to prevent users from
needing to deal with two GUCs. For all practical purposes, it would be
possible to change autovacuum_max_workers whenever you want. But if the
extra resource requirements are too much of a tax, I'm content to change
course.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-06-18 21:13:08 | Re: cost delay brainstorming |
Previous Message | Tom Lane | 2024-06-18 20:48:18 | Re: Xact end leaves CurrentMemoryContext = TopMemoryContext |