| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(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-15 03:15:47 |
| Message-ID: | CALj2ACVY4GwXjU4fqht-SRPqGV258Ps9R255MjyU0YA0Quc0PA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Wed, Oct 14, 2026 at 12:14 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> > 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.
>
> I'm not sure how helpful it is for users in practice.
>
> 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.
I have seen a few cases where the heap scanning phase takes a long
time on larger tables, though it depends on the workload. Upon
thinking more, without field reports, honoring only the downsizing
while ignoring the upsizing doesn't look right to me. And I agree that
to speed up or slow down vacuuming on large tables and indexes, one
can change the cost params.
> 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.
Agreed, I didn't mean this as a bug fix or PG19 open item. And, for
both parallel vacuum and parallel autovacuum, the number of parallel
workers is fixed when the vacuum starts.
That said, I'm fine to leave this as is. Perhaps a simple note in the
"Parallel Vacuum" docs like the following would help, but please feel
free to ignore it.
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index fc89c03279b..e1fbfec86ab 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1212,6 +1212,14 @@ analyze threshold = analyze base threshold +
analyze scale factor * number of tu
all.
</para>
+ <para>
+ The number of parallel workers is determined before the
+ <literal>scanning heap</literal> phase begins and stays fixed for the rest
+ of that table's vacuum. Changing any of the above limits therefore has no
+ effect on a vacuum already in progress. The new values apply to subsequent
+ vacuum operations.
+ </para>
+
<para>
An index can participate in parallel vacuum if and only if the size of the
index is more than <xref linkend="guc-min-parallel-index-scan-size"/>.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-10-15 03:18:33 | Weird usages of sentinel_ok() |
| Previous Message | Tender Wang | 2026-10-15 03:13:07 | Re: Wrong results from self-join elimination with different restriction operators |