Hi, On Tue, Oct 13, 2026 at 8:17 PM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > I noticed that we don't honor a reduced number of parallel workers for > parallel autovacuum. This means a lowered > autovacuum_max_parallel_workers can't take effect after a long heap > scan phase on a table of hundreds of GBs or even TBs. Note that we can > only downsize, upsizing is not possible because the DSM is sized in > parallel_vacuum_init() before the heap scan phase of the vacuum. > > Please find the attached patch fixing this. > > Thoughts?
Thank you for the report and the patch! I'm not sure how helpful it is for users in practice. With the patch, a new value takes effect only when the next index vacuuming or index cleanup phase starts, so changing it while parallel workers are running doesn't help, even though index vacuuming could take a long time. Given that vacuum requires only one index acuuming pass in most cases since v17, there would practically be only one chance to reduce the parallel workers. Also, I think if users want to reduce the workload from parallel vacuum, they can dynamically tune the cost-based delay parameters instead, which are propagated to the parallel workers. Also, I'd like to make it clear that this is not a fix for the parallel autovacuum feature in v19 but rather an improvement. Both VACUUM (PARALLEL) and parallel autovacuum determine the parallel degree when the vacuum starts, which is consistent, and I don't think it's a bug. So I don't think we should treat it as a v19 open item. We can discuss it as an improvement for v20, though. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
