Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Date: 2020-09-19 09:37:47
Message-ID: CAA4eK1LQWXS_4RwLo+WT7jusGnBkUvXO73xQOCsydWLYBpLBEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 19, 2020 at 1:58 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-09-19 10:59:02 Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Previous Message Peter Eisentraut 2020-09-19 08:28:59 VACUUM PARALLEL option vs. max_parallel_maintenance_workers