Re: parallel vacuum options/syntax - Mailing list pgsql-hackers

On Sun, 5 Jan 2020 at 22:39, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>
> 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.

Okay I got your point. It's just an idea but how about controlling
parallel vacuum using two options. That is, we have PARALLEL option
that takes a boolean value (true by default) and enables/disables
parallel vacuum. And we have WORKERS option that takes an integer more
than 1 to specify the number of workers. Of course we should raise an
error if only WORKERS option is specified. WORKERS option is optional.
If WORKERS option is omitted the number of workers is determined based
on the number of indexes on the table.

Regards,

-- 
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services