> 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
