On Tue, Sep 22, 2020 at 12:50 PM David Rowley <dgrowle...@gmail.com> wrote: > > On Mon, 21 Sep 2020 at 19:15, Peter Eisentraut > <peter.eisentr...@2ndquadrant.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.