Le jeu. 2 janv. 2020 à 13:09, Amit Kapila <amit.kapil...@gmail.com> a écrit :
> Hi, > > I am starting a new thread for some of the decisions for a parallel vacuum > in the hope to get feedback from more people. There are mainly two points > for which we need some feedback. > > 1. Tomas Vondra has pointed out on the main thread [1] that by default the > parallel vacuum should be enabled similar to what we do for Create Index. > As proposed, the patch enables it only when the user specifies it (ex. > Vacuum (Parallel 2) <tbl_name>;). One of the arguments in favor of > enabling it by default as mentioned by Tomas is "It's pretty much the same > thing we did with vacuum throttling - it's disabled for explicit vacuum by > default, but you can enable it. If you're worried about VACUUM causing > issues, you should set cost delay.". Some of the arguments against > enabling it are that it will lead to use of more resources (like CPU, I/O) > which users might or might like. > > Now, if we want to enable it by default, we need a way to disable it as > well and along with that, we need a way for users to specify a parallel > degree. I have mentioned a few reasons why we need a parallel degree for > this operation in the email [2] on the main thread. > > 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. So, (c) has my vote. 2. The patch provides a FAST option (based on suggestion by Robert) for a > parallel vacuum which will make it behave like vacuum_cost_delay = 0 which > means it will disable throttling. So, > VACUUM (PARALLEL n, FAST) <tbl_name> will allow the parallel vacuum to run > without resource throttling. Tomas thinks that we don't need such an > option as the same can be served by setting vacuum_cost_delay = 0 which is > a valid argument, but OTOH, providing an option to the user which can make > his life easier is not a bad idea either. > > The user already has an option (the vacuum_cost_delay GUC). So I kinda agree with Tomas on this. -- Guillaume.