Re: POC: Parallel processing of indexes in autovacuum - Mailing list pgsql-hackers

On Wed, Apr 1, 2026 at 2:24 PM Daniil Davydov <3danissimo@gmail.com> wrote:
>
> Hi,
>
> On Wed, Apr 1, 2026 at 7:10 PM Alexander Korotkov <aekorotkov@gmail.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.

Thank you for updating the patch! I found a bug in the following code:

@@ -457,6 +534,9 @@ parallel_vacuum_end(ParallelVacuumState *pvs,
IndexBulkDeleteResult **istats)
  DestroyParallelContext(pvs->pcxt);
  ExitParallelMode();

+ if (AmAutoVacuumWorkerProcess())
+ pv_shared_cost_params = NULL;
+

If an autovacuum worker raises an error during parallel vacuum, it
doesn't pv_shared_cost_params. Then, if it doesn't use parallel vacuum
on the next table to vacuum, it would end up with SEGV as it attempts
to propagate the vacuum delay parameters.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com