On Thu, Jan 2, 2020 at 7:09 PM Guillaume Lelarge <guillaume@lelarge.info> wrote: > > Le jeu. 2 janv. 2020 à 13:09, Amit Kapila <amit.kapila16@gmail.com> a écrit : >> >> 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? >> > > AFAICT, every parallel-able statement use parallelisation by default, so it wouldn't be consistent if VACUUM behaves some other way. >
Fair enough.
> So, (c) has my vote. >
I don't understand this. What do you mean by voting (c) option? Do you mean that you didn't like any of (a) or (b)?
I meant (b), sorry :)
If so, then feel free to suggest something else. One more possibility could be to allow users to specify parallel degree or disable parallelism via guc 'max_parallel_maintenance_workers'. Basically, if the user wants to disable parallelism, it needs to set the value of guc max_parallel_maintenance_workers as zero and if it wants to increase the parallel degree than the default value (which is two), then it can set it via max_parallel_maintenance_workers before running vacuum command. Now, this can certainly work, but I feel setting/resetting a guc before a vacuum command can be a bit inconvenient for users, but if others prefer that way, then we can do that.
