Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

On Tue, Sep 22, 2020 at 3:20 AM David Rowley <dgrowleyml(at)gmail(dot)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. It doesn't have a Gather
node that might be subject to one limit and a Seq Scan that can be
subjected to some other limit. So to me the idea that the command line
option doesn't override the GUC is completely strange, especially
because OTHER parameters to VACUUM *do* have precisely the effect of
overriding GUCs or reloptions. In particular, FREEZE overrides
vacuum_freeze_min_age and vacuum_freeze_table_age, and TRUNCATE and
INDEX_CLEANUP override the vacuum_truncate and vacuum_index_cleanup
reloptions.

So I agree with Peter that the implemented behavior is wrong.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company