Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

On Tue, Sep 22, 2020 at 12:50 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Mon, 21 Sep 2020 at 19:15, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> >
> > On 2020-09-21 05:48, Amit Kapila wrote:
> > > What according to you should be the behavior here and how will it be
> > > better than current?
> >
> > I think if I write VACUUM (PARALLEL 5), it should use up to 5 workers
> > (up to the number of indexes), even if max_parallel_maintenance_workers
> > is 2.
>
> It would be good if we were consistent with these parallel options.
> Right now max_parallel_workers_per_gather will restrict the
> parallel_workers reloption. I'd say this
> max_parallel_workers_per_gather is similar to
> max_parallel_maintenance_workers here and the PARALLEL vacuum option
> is like the parallel_workers reloption.
>
> If we want VACUUM's parallel option to work the same way as that then
> max_parallel_maintenance_workers should restrict whatever is mentioned
> in VACUUM PARALLEL.
>
> Or perhaps this is slightly different as the user is explicitly asking
> for this in the command, but you could likely say the same about ALTER
> TABLE <table> SET (parallel_workers = N); too.
>

This is exactly my feeling too. But how about changing documentation a
bit as proposed above [1] to make it precise.

[1] - https://www.postgresql.org/message-id/CAA4eK1LQWXS_4RwLo%2BWT7jusGnBkUvXO73xQOCsydWLYBpLBEg%40mail.gmail.com

--
With Regards,
Amit Kapila.