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)? 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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
