Re: parallel vacuum options/syntax

Amit Kapila <[email protected]>
Newsgroups gmane.comp.db.postgresql.devel.general
Message-ID <CAA4eK1J2iG1YCtWCHL_--7LwvCuPZLpDf76EPdWQpnqJuNgWjA@mail.gmail.com>
On Fri, Jan 3, 2020 at 8:50 AM Dilip Kumar <[email protected]> wrote:
>
> On Thu, Jan 2, 2020 at 5:39 PM Amit Kapila <[email protected]> wrote:
> >
> > If parallel vacuum is *not* enabled by default, then I think the current way to enable is fine which is as follows:
> > Vacuum (Parallel 2) <tbl_name>;
> >
> > Here, if the user doesn't specify parallel_degree, then we internally decide based on number of indexes that support a parallel vacuum with a maximum of max_parallel_maintenance_workers.
> >
> > If the parallel vacuum is enabled by default, then I could think of the following ways:
> > (a) Vacuum (disable_parallel) <tbl_name>;  Vacuum (Parallel <parallel_degree>) <tbl_name>;
> > (b) Vacuum (Parallel <parallel_degree>) <tbl_name>;  If user specifies parallel_degree as 0, then disable parallelism.
> > (c) ... Any better ideas?
>
> IMHO, it's better to keep the parallelism enables by default.  Because
> if the user is giving an explicit vacuum then better to keep it fast
> by default.

Okay.

>  However, I agree that we can provide an option for the
> user to disable it and provide the parallel degree with the vacuum
> command something like option (b).
>

The option (b) has some advantage over (a) that we don't need to
invent multiple options to enable/disable parallelism for vacuum.
However, it might appear awkward to set parallel_degree as 0 (Vacuum
(Parallel 0) tbl_name) to disable parallelism.  Having said that, we
already have some precedence wherein if we set parameters like
statement_timeout, lock_timeout, etc to zero, it disables the timeout.
So, it won't be insane if we choose this option.

Does anyone else have any opinion on what makes sense here?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.