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
aparallel 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
someother 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