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