Re: POC: Parallel processing of indexes in autovacuum

From: Daniil Davydov <3danissimo(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: Parallel processing of indexes in autovacuum
Date: 2026-04-01 21:24:29
Message-ID: CAJDiXgjctmV-vLSjSQFxkANT-VZzwjJCmYGcJQ_y3+TkjxcrWg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Apr 1, 2026 at 7:10 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> Thank you for your work on this subject! I've some notes about the patch.
>

Thank you very much for the review!

> 1) The changes in guc.c allows autovacuum parallel leader to accept
> changes in not just cost-based GUCs, but any GUCs. That should be no
> problem, because parallel workers have their own copies of GUC
> variables, but I think this worth comment.

OK, I will clarify it in the code.

> 2) Maximum value for autovacuum_parallel_workers reloption is defined
> as literally 1024, while max value for autovacuum_max_parallel_workers
> is defined as MAX_PARALLEL_WORKER_LIMIT (also 1024). Should we define
> max value for reloption as MAX_PARALLEL_WORKER_LIMIT as well?

I agree.

> 3) Some paragraphs were moved from vacuum.sgml to maintenance.sgml.
> It particular it references <replaceable
> class="parameter">integer</replaceable, which is related to PARALLEL
> option syntax: (PARALLEL integer). Now it becoming unclear and needs
> to be revised.

Good catch! You are right.

> 4) I also think maintenance.sgml should mention the new reloption.

Do you mean that we should mention it in the "parallel-vacuum" chapter? If so,
I think that we should also mention that max_parallel_maintenance_workers can
affect the parallel degree of manual VACUUM command. Yes, we have already
written about this in the description of the PARALLEL option. But now the
"vacuum-parallel" chapter doesn't mention limiting by GUC for manual VACUUM and
limiting by reloption for autovacuum. IMHO it is better to have redundancy than
an incomplete description.

> 5) I think it worth having a test which check that setting
> autovacuum_parallel_workers to 0 disables the parallel autovacuum for
> given table.

I see that VACUUM (PARALLEL) doesn't have such a test. Both manual VACUUM and
autovacuum have similar logic with parallelism disabling. Is the increase in
test completion time really worth checking these logic? I don't mind adding a
new test, actually. Just want to make sure that this is necessary.

> 6) Minor grammar issue in PVSharedCostParams comment, it must be
> "vacuum workers compare" (plural subject).

Yep, I'll fix it.

Please, see an updated patch.

--
Best regards,
Daniil Davydov

Attachment Content-Type Size
v36-0001-Allow-autovacuum-to-use-parallel-vacuum-workers.patch text/x-patch 42.9 KB
v35-v36-diff.patch text/x-patch 5.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-04-01 21:28:45 Re: Add pg_stat_autovacuum_priority
Previous Message Bharath Rupireddy 2026-04-01 21:21:13 Re: Introduce XID age based replication slot invalidation