From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
Cc: | 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-05-03 01:04:15 |
Message-ID: | 20240503010415.GA1008894@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-05-03 02:51:40 | improve performance of pg_dump with many sequences |
Previous Message | Tom Lane | 2024-05-03 00:18:59 | Re: Weird "null" errors during DROP TYPE (pg_upgrade) |