| From: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Doc fix for autovacuum_max_parallel_workers |
| Date: | 2026-10-15 21:21:03 |
| Message-ID: | CAN12+Y+0SensRyvyF5JLRUpkD5ZB2v=EobW-L4fFu+e3hNMHAA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>
>>
>> I agree. It should do something similar to [1] for consistency.
>
> Thank you for the confirmation, Sami. v2 added. I followed the format of other
> autovacuum params which don't specifically point to the related storage parameters.
I had this wording in mind:
"This parameter can only be set in the <filename>postgresql.conf</filename>
file or on the server command line; but the setting can be overridden for
individual tables by changing the
<link linkend="reloption-autovacuum-parallel-workers">corresponding table
storage parameter</link>."
That seems more helpful and matches [1], because it points to the specific
table storage parameter. In this case the reloption is named
autovacuum_parallel_workers while the GUC is autovacuum_max_parallel_workers,
so a link makes that clearer.
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-10-15 21:25:37 | Re: PoC: Simplify recovery after dropping a table by LOGGING the restore LSN |
| Previous Message | Masahiko Sawada | 2026-10-15 21:14:26 | Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers |