Re: POC: Parallel processing of indexes in autovacuum

From: Daniil Davydov <3danissimo(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(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: 2025-11-23 15:02:22
Message-ID: CAJDiXgjt5ZmK2uvS0E8Ztt5ePYmq8Ze_dG05Zo2NUsKLHCEuYA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, Nov 23, 2025 at 5:51 AM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
>
> > > nworkers has a double meaning. The return value of
> > > AutoVacuumReserveParallelWorkers
> > > is nreserved. I think this should be
> > >
> > > ```
> > > nreserved = AutoVacuumReserveParallelWorkers(nworkers);
> > > ```
> > >
> > > and nreserved becomes the authoritative value for the number of parallel
> > > workers after that point.
>
> I could not find this pattern being used in the code base.
> I think it will be better and more in-line without what we generally do
> and pass-by-reference and update the value inside
> AutoVacuumReserveParallelWorkers:
>
> ```
> AutoVacuumReserveParallelWorkers(&nworkers).
> ```

Maybe I just don't like functions with side effects, but this function will
have ones anyway. I'll add logic with passing by reference as you
suggested.

>
> >> ---
> >> { name => 'autovacuum_max_parallel_workers', type => 'int', context =>
> >> 'PGC_SIGHUP', group => 'VACUUM_AUTOVACUUM',
> >> short_desc => 'Maximum number of parallel autovacuum workers, that
> >> can be taken from bgworkers pool.',
> >> long_desc => 'This parameter is capped by "max_worker_processes"
> >> (not by "autovacuum_max_workers"!).',
> >> variable => 'autovacuum_max_parallel_workers',
> >> boot_val => '0',
> >> min => '0',
> >> max => 'MAX_BACKENDS',
> >> },
> >>
> >> Parallel vacuum in autovacuum can be used only when users set the
> >> autovacuum_parallel_workers storage parameter. How about using the
> >> default value 2 for autovacuum_max_parallel_workers GUC parameter?
>
> > Sounds reasonable, +1 for it.
>
> v15-0004 has an incorrect default value for `autovacuum_max_parallel_workers`.
> It should now be 2.
>
> + Sets the maximum number of parallel autovacuum workers that
> + can be used for parallel index vacuuming at one time. Is capped by
> + <xref linkend="guc-max-worker-processes"/>. The default is 0,
> + which means no parallel index vacuuming.

Thanks for noticing it! Fixed.

I am sending an updated set of patches.

--
Best regards,
Daniil Davydov

Attachment Content-Type Size
v16-0003-Tests-for-parallel-autovacuum.patch text/x-patch 19.2 KB
v16-0004-Documentation-for-parallel-autovacuum.patch text/x-patch 4.4 KB
v16-0001-Parallel-autovacuum.patch text/x-patch 19.8 KB
v16-0002-Logging-for-parallel-autovacuum.patch text/x-patch 7.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2025-11-23 15:02:29 Re: Trying out <stdatomic.h>
Previous Message Tomas Vondra 2025-11-23 14:53:17 Re: should we have a fast-path planning for OLTP starjoins?