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