On Fri, Jan 3, 2020 at 8:50 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Thu, Jan 2, 2020 at 5:39 PM Amit Kapila <amit.kapila16@gmail.com> 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
supporta 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
