Re: allow changing autovacuum_max_workers without restarting

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