On Wed, Sep 30, 2020 at 9:23 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 3:20 AM David Rowley <dgrowleyml@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.
