Le ven. 3 janv. 2020 à 09:06, Amit Kapila <amit.kapil...@gmail.com> a écrit :
> On Thu, Jan 2, 2020 at 7:09 PM Guillaume Lelarge <guilla...@lelarge.info> > wrote: > > > > Le jeu. 2 janv. 2020 à 13:09, Amit Kapila <amit.kapil...@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. > > -- Guillaume.
