| 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: | Whole Thread | Raw Message | 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
| 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 |