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

From Sami Imseih
Subject Re: POC: Parallel processing of indexes in autovacuum
Date
Msg-id CAA5RZ0tbiPcgQEjnhdnjz6qSjfRsGrr8jGCaMcrMaoPpax3wig@mail.gmail.com
Whole thread Raw
In response to Re: POC: Parallel processing of indexes in autovacuum  (Daniil Davydov <3danissimo@gmail.com>)
Responses Re: POC: Parallel processing of indexes in autovacuum
List pgsql-hackers
> > 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 that's just my preference.

>> ---
>> { 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.

--
Sami



pgsql-hackers by date:

Previous
From: Greg Burd
Date:
Subject: Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ​barriers
Next
From: Jim Jones
Date:
Subject: Re: Add notification on BEGIN ATOMIC SQL functions using temp relations