On Sun, Jan 05, 2020 at 03:56:35PM +0530, Amit Kapila wrote:
>>
>> ...
>>
>> >If parallel vacuum is enabled by default, I would prefer (b) but I
>> >don't think it's a good idea to accept 0 as parallel degree. If we want
>> >to disable parallel vacuum we should max_parallel_maintenance_workers
>> >to 0 instead.
>> >
>>
>> IMO that just makes the interaction between vacuum options and the GUC
>> even more complicated/confusing.
>>
>
>Yeah, I am also not sure if that will be a good idea.
>
>> If we want to have a vacuum option to determine parallel degree, we
>> should probably have a vacuum option to disable parallelism using just a
>> vacuum option. I don't think 0 is too bad, and disable_parallel seems a
>> bit awkward. Maybe we could use NOPARALLEL (in addition to PARALLEL n).
>> That's what Oracle does, so it's not entirely without a precedent.
>>
>
>We can go either way (using 0 for parallel to indicate disable
>parallelism or by introducing a new option like NOPARALLEL). I think
>initially we can avoid introducing more options and just go with
>'Parallel 0' and if we find a lot of people find it inconvenient, then
>we can always introduce a new option later.
>
I don't think starting with "parallel 0" and then maybe introducing
NOPARALLEL sometime in the future is a good plan, because after adding
NOPARALLEL we'd either have to remove "parallel 0" (breaking backwards
compatibility unnecessarily) or supporting both approaches.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
