On Wed, Sep 30, 2020 at 9:23 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Sep 22, 2020 at 3:20 AM David Rowley <dgrowle...@gmail.com> wrote: > > 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. > > There is a subtle difference between these two cases. In the case of a > query, there may be multiple table scans involved, all under the same > Gather node. So a limit on the Gather node is to some degree a > separate constraint on the overall query plan from the reloption > applied to a particular table. So there is at least some kind of an > argument that it's sensible to combine those limits somehow. I'm not > sure I believe it, though. The user probably wants exactly the number > of workers they specify, not the GUC value. > > However, in the VACUUM case, there's no possibility of distinguishing > between the parallel operation as a whole and the expectations for a > particular table. It's a single operation. >
But the same is true for the 'Create Index' operation as well where we follow the same thing. We will use the number of workers as specified in reloption (parallel_workers) which is then limited by max_parallel_maintenance_workers. -- With Regards, Amit Kapila.
