From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allow changing autovacuum_max_workers without restarting |
Date: | 2024-04-15 17:41:04 |
Message-ID: | 96B4FC7B-A919-4F93-80A3-BA3EA4F8479A@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
> When I thought about this, I considered proposing to add a new GUC for
> "autovacuum_policy_workers".
> autovacuum_max_workers would be the same as before, requiring a restart
> to change. The policy GUC would be the soft limit, changable at runtime
I think autovacuum_max_workers should still be the GUC that controls
the number of concurrent autovacuums. This parameter is already well
established and changing the meaning now will be confusing.
I suspect most users will be glad it's now dynamic, but will probably
be annoyed if it's no longer doing what it's supposed to.
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-04-15 17:43:28 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Previous Message | Nazir Bilal Yavuz | 2024-04-15 16:41:19 | Re: Table AM Interface Enhancements |