Re: parallel vacuum options/syntax

From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: parallel vacuum options/syntax
Date: 2020-01-08 06:01:17
Message-ID: CA+fd4k5bjf4FkGWU864Fiyxfybr=8k5rVYJue5yR1Lvj-=X8cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 6 Jan 2020 at 15:27, Masahiko Sawada
<masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
>
> 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.
>

Okay I'm going to go with enabling parallel vacuum by default and
disabling it by specifying PARALLEL 0.

For combination of VACUUM command options, although parallel vacuum is
enabled by default and VACUUM FULL doesn't support it yet, 'VACUUM
(FULL)' would work. On the other hand 'VACUUM (FULL, PARALLEL)' and
'VACUUM(FULL, PARALLEL 1)' would not work with error. And I think it
is better if 'VACUUM (FULL, PARALLEL 0)' also work but I'd like to
hear opinions.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-01-08 06:31:38 Re: parallel vacuum options/syntax
Previous Message Thomas Munro 2020-01-08 04:56:52 Re: [PATCH] lazy relations delete