Re: parallel vacuum options/syntax

Tomas Vondra <[email protected]>
Newsgroups gmane.comp.db.postgresql.devel.general
Message-ID <20200105115910.wfxxfpft4pvqxm6j@development>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.