On Tue, Jun 18, 2024 at 01:43:34PM -0700, Andres Freund wrote: > I just don't see much point in reserving 256 worker "possibilities", tbh. I > can't think of any practical system where it makes sense to use this much (nor > do I think it's going to be reasonable in the next 10 years) and it's just > going to waste memory and startup time for everyone.
Given this, here are some options I see for moving this forward: * lower the cap to, say, 64 or 32 * exclude autovacuum worker slots from computing number of locks, etc. * make the cap configurable and default it to something low (e.g., 8) My intent with a reserved set of 256 slots was to prevent users from needing to deal with two GUCs. For all practical purposes, it would be possible to change autovacuum_max_workers whenever you want. But if the extra resource requirements are too much of a tax, I'm content to change course. -- nathan
