Re: Parallel autovacuum: honor reduced parallel workers after heap scan phase

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parallel autovacuum: honor reduced parallel workers after heap scan phase
Date: 2026-10-14 19:14:01
Message-ID: CAD21AoDVbsN=6dwM=EbyqLc3sYTmbK6i5uG7bar8nH-=z98o7w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Oct 13, 2026 at 8:17 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-10-14 19:14:10 Re: Perf: Specialize ExecIndexOnlyScan() like ExecSeqScan()
Previous Message alvherre@kurilemu.de 2026-10-14 18:15:28 Re: Bug in logical decoding with DDL and subtransactions