On 2020-09-19 13:24, Amit Kapila wrote:
>> I think the implemented behavior is wrong.
>
> It is the same as what we do for other parallel operations, for
> example, we limit the number of parallel workers for parallel create
> index by 'max_parallel_maintenance_workers' and parallel scan
> operations are limited by 'max_parallel_workers_per_gather'.
But in those cases we don't provide user-visible options to specify a
per-command setting, so it's not the same thing, is it?
>> The VACUUM PARALLEL option
>> should override the max_parallel_maintenance_worker setting.
>>
>> Otherwise, what's the point of the command option?
>
> It is for the cases where the user has a better idea of workload. We
> can launch only a limited number of parallel workers
> 'max_parallel_workers' in the system, so sometimes users would like to
> use it as per their requirement.
Right, but my point is, it doesn't actually do that correctly. I can't
just say, oh, I have a maintenance window, I'd like to run a really fast
VACUUM. The PARALLEL option is capped by the setting you'd normally use
anyway, so specifying it is useless.
The only thing it can do right now is if you want to run a manual VACUUM
less parallel than by default. But I don't see how that is often useful.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services