On Mon, Apr 15, 2024 at 11:28:33AM -0500, Nathan Bossart wrote: > On Mon, Apr 15, 2024 at 08:33:33AM -0500, Justin Pryzby wrote: >> On Wed, Apr 10, 2024 at 04:23:44PM -0500, Nathan Bossart wrote: >>> The proof-of-concept patch keeps autovacuum_max_workers as the maximum >>> number of slots to reserve for workers, but I think we should instead >>> rename this parameter to something else and then reintroduce >>> autovacuum_max_workers as the new parameter that can be adjusted without >>> restarting. That way, autovacuum_max_workers continues to work much the >>> same way as in previous versions. >> >> 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 >> up to the hard limit of autovacuum_max_workers (or maybe any policy >> value exceeding autovacuum_max_workers would be ignored). >> >> We'd probably change autovacuum_max_workers to default to a higher value >> (8, or 32 as in your patch), and have autovacuum_max_workers default to >> 3, for consistency with historic behavior. Maybe >> autovacuum_policy_workers=-1 would mean to use all workers. > > This sounds like roughly the same idea, although it is backwards from what > I'm proposing in the v1 patch set. My thinking is that by making a new > restart-only GUC that would by default be set higher than the vast majority > of systems should ever need, we could simplify migrating to these > parameters. The autovacuum_max_workers parameter would effectively retain > it's original meaning, and existing settings would continue to work > normally on v18, but users could now adjust it without restarting. If we > did it the other way, users would need to bump up autovacuum_max_workers > and restart prior to being able to raise autovacuum_policy_workers beyond > what they previously had set for autovacuum_max_workers. That being said, > I'm open to doing it this way if folks prefer this approach, as I think it > is still an improvement.
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. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
