Agree +1,From a dba perspective, I would prefer that this parameter can be dynamically modified, rather than adding a new parameter,What is more difficult is how to smoothly reach the target value when the setting is considered to be too large and needs to be lowered.
Regards On Tue, 16 Apr 2024 at 01:41, Imseih (AWS), Sami <sims...@amazon.com> 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. > > > 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 > >
