On Thu, Oct 15, 2020 at 9:02 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Oct 5, 2020 at 8:11 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada > > <masahiko.saw...@2ndquadrant.com> wrote: > > > > > > To make the behavior of parallel vacuum more consistent with other > > > parallel maintenance commands (i.g., only parallel INDEX CREATE for > > > now), as a second idea, can we make use of parallel_workers reloption > > > in parallel vacuum case as well? That is, when PARALLEL option without > > > an integer is specified or VACUUM command without PARALLEL option, the > > > parallel degree is the number of indexes that support parallel vacuum > > > and are bigger than min_parallel_index_scan_size. If the > > > parallel_workers reloption of the table is set we use it instead. In > > > both cases, the parallel degree is capped by > > > max_parallel_maintenance_workers. OTOH when PARALLEL option with an > > > integer is specified, the parallel degree is the specified integer > > > value and it's capped by max_parallel_workers and the number of > > > indexes that support parallel vacuum and are bigger than > > > min_parallel_index_scan_size. > > > > > > > This seems more difficult to explain and have more variable parts. I > > think one of the blogs I recently read about this work [1] (see > > section: > > Parallel VACUUM & Better Support for Append-only Workloads) explains > > the currently implemented behavior (related to the workers) nicely and > > in simple words. Now unless I or the person who wrote that blog missed > > something it appears to me that the current implemented behavior is > > understood by others who might not be even directly involved in this > > work which to some extent indicates that users will be able to use > > currently implemented behavior without difficulty. I think we can keep > > the current behavior as it is and wait to see if we see any complaints > > from the users trying to use it. > > > > I am planning to commit the patch (by early next week) posted above > thread [1] to make the docs consistent with what we have in code. >
Pushed. -- With Regards, Amit Kapila.
