Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Date
Msg-id CAA4eK1LQWXS_4RwLo+WT7jusGnBkUvXO73xQOCsydWLYBpLBEg@mail.gmail.com
Whole thread Raw
In response to VACUUM PARALLEL option vs. max_parallel_maintenance_workers  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Sat, Sep 19, 2020 at 1:58 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> If I read the code correctly, the VACUUM PARALLEL option is capped by
> the active max_parallel_maintenance_workers setting.  So if I write
> VACUUM (PARALLEL 5), it will still only do 2 by default.  Is that
> correct?

Yeah, but there is another factor also which is the number of indexes
that support parallel vacuum operation.

>  The documentation (VACUUM man page) seems to indicate a
> different behavior.
>

I think we can change the documentation for parallel option to explain
it better. How about: "Perform index vacuum and index cleanup phases
of VACUUM in parallel using integer background workers (for the
details of each vacuum phase, please refer to Table 27.37). The number
of workers is determined based on the number of indexes on the
relation that support parallel vacuum operation which is limited by
number of workers specified with PARALLEL option if any which is
further limited by max_parallel_maintenance_workers." instead of what
is currently there?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Next
From: Peter Eisentraut
Date:
Subject: Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers