On Sun, Jan 05, 2020 at 09:17:57PM +0900, Masahiko Sawada wrote:
>On Sun, Jan 5, 2020 at 7:26 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> ...
>>
>> > 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.
>
>Hmm I'm confused. Specifying NOPARALLEL or PARALLEL 0 is the same as
>setting max_parallel_maintenance_workers to 0, right? We normally set
>max_parallel_workers_per_gather to 0 to disable parallel queries on a
>query. So I think that disabling parallel vacuum by setting
>max_parallel_maintenance_workers to 0 is the same concept. Regarding
>proposed two options we already have storage parameter
>parallel_workers and it accepts 0 but PARALLEL 0 looks like
>contradicted at a glance. And NOPARALLEL is inconsistent with existing
>DISABLE_XXX options and it's a bit awkward to specify like (NOPARALLEL
>off).
>
My understanding is the motivation for new vacuum options is a claim
that m_p_m_w is not sufficient/suitable for the vacuum case. I've
expressed my doubts about this, but let's assume it's the right
solution. To me it seems a bit confusing to just fall back to m_p_m_w
when it comes to disabling the parallel vacuum.
So if we think we need an option to determine vacuum parallel degree, we
should have an option to disable parallelism too. I don't care much if
it's called DISABLE_PARALLEL, NOPARALLEL or PARALLEL 0, as long as we
make our mind and don't unnecessarily break it in the next release.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
