Re: parallel vacuum options/syntax

On Sun, 5 Jan 2020 at 23:28, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sun, Jan 5, 2020 at 7:38 PM Masahiko Sawada
> <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
> >
> > On Sun, 5 Jan 2020 at 22:39, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> > >
> > >
> > > 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.
> > >
>
> Fair point. I favor parallel 0 as that avoids adding more options and
> also it is not very clear whether that is required at all. Till now,
> if I see most people who have shared their opinion seems to favor this
> as compared to another idea where we need to introduce more options.
>
> >
> > 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.
> >
>
> I think this would add failure modes without serving any additional
> purpose. Sure, it might give the better feeling that we have separate
> options to enable/disable parallelism and then specify the number of
> workers with a separate option, but we already have various examples
> as shared by me previously where setting the value as zero means the
> option is disabled, so why to invent something new here?

I just felt it's not intuitive that specifying parallel degree to 0
means to disable parallel vacuum. But since majority of hackers seem
to agree with this syntax I'm not going to insist on that any further.

Regards,

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