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. 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
