Re: POC: Parallel processing of indexes in autovacuum

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Daniil Davydov <3danissimo(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(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-04 01:11:58
Message-ID: CAD21AoBwzPC-oo=yyfdVBC6hadjOSbKyHSs7bH7DqPUamAEZfg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 3, 2026 at 6:45 AM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Fri, Apr 3, 2026 at 6:00 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Thu, Apr 2, 2026 at 8:10 AM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
> > >
> > > I think we should add some cleanup for autovacuum near the ParallelContext
> > > cleanup, since they are interconnected. I also want to return our tests that
> > > are triggering ERROR/PANIC in the leader worker in order to check whether all
> > > resources are released. I hope I will be able to get to that by tomorrow
> > > evening.
> >
> > I think that the beginning of vacuum loop (in PG_TRY() block in
> > vacuum()) seems better place as we're resetting vacuum delay
> > parameters:
> >
> > in_vacuum = true;
> > VacuumFailsafeActive = false;
> > VacuumUpdateCosts();
> > VacuumCostBalance = 0;
> > VacuumCostBalanceLocal = 0;
> > VacuumSharedCostBalance = NULL;
> > VacuumActiveNWorkers = NULL;
> >
>
> I am still thinking that this pointer is related to the ParallelContext, and it
> is a bit confusing that we can manipulate it outside all "parallel" logic.
> Since this variable points to the DSM it looks very natural for me if its
> lifetime will be similar to the DSM. Please, see attached patch, that resets
> this pointer during dsm detaching.

Sounds a reasonable apporach.

Regarding the regression tests, ISTM we no longer need
'autovacuum-leader-before-indexes-processing' injection point since it
currently tests that parallel workers update their delay parameters
during the initialization (i.e., in parallel_vacuum_main()). In order
to verify the behavior of workers updating their delay parameters
while processing indexes, we would need another injection ponit to
stop parallel workers, which seems overkill to me. So I removed it but
the test still covers the propagation logic.

Regarding the patch, I don't think it's a good idea to include
bgworker_internals.h from reloptions.c:

@@ -28,6 +28,7 @@
#include "commands/defrem.h"
#include "commands/tablespace.h"
#include "nodes/makefuncs.h"
+#include "postmaster/bgworker_internals.h"
#include "storage/lock.h"
#include "utils/array.h"
#include "utils/attoptcache.h"
@@ -236,6 +237,15 @@ static relopt_int intRelOpts[] =
},
SPGIST_DEFAULT_FILLFACTOR, SPGIST_MIN_FILLFACTOR, 100
},
+ {
+ {
+ "autovacuum_parallel_workers",
+ "Maximum number of parallel autovacuum workers that can be
used for processing this table.",
+ RELOPT_KIND_HEAP,
+ ShareUpdateExclusiveLock
+ },
+ -1, -1, MAX_PARALLEL_WORKER_LIMIT
+ },

I'd leave the maximum value as 1024.

I've attached patch and please check it. I think it's a good shape and
I'm going to push it next Monday barrying objections.

Regards,

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

Attachment Content-Type Size
v37-0001-Allow-autovacuum-to-use-parallel-vacuum-workers.patch text/x-patch 42.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-04-04 01:24:55 Re: AIO / read stream heuristics adjustments for index prefetching
Previous Message Thomas Munro 2026-04-04 01:07:04 Re: pg_waldump: support decoding of WAL inside tarfile