Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

On Sat, Sep 19, 2020 at 4:28 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> On 2020-09-19 11:37, Amit Kapila wrote:
> > 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?
>
> I think the implemented behavior is wrong.
>

It is the same as what we do for other parallel operations, for
example, we limit the number of parallel workers for parallel create
index by 'max_parallel_maintenance_workers' and parallel scan
operations are limited by 'max_parallel_workers_per_gather'.

> The VACUUM PARALLEL option
> should override the max_parallel_maintenance_worker setting.
>
> Otherwise, what's the point of the command option?
>

It is for the cases where the user has a better idea of workload. We
can launch only a limited number of parallel workers
'max_parallel_workers' in the system, so sometimes users would like to
use it as per their requirement. If the user omits this option, then
we internally compute the required number of workers but again those
are limited by max_* guc's.

--
With Regards,
Amit Kapila.