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
