Re: allow changing autovacuum_max_workers without restarting

From: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow changing autovacuum_max_workers without restarting
Date: 2024-04-15 17:41:04
Message-ID: 96B4FC7B-A919-4F93-80A3-BA3EA4F8479A@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-04-15 17:43:28 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Previous Message Nazir Bilal Yavuz 2024-04-15 16:41:19 Re: Table AM Interface Enhancements