Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

On Mon, Oct 5, 2020 at 8:11 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, Oct 3, 2020 at 6:55 PM Masahiko Sawada
> <masahiko(dot)sawada(at)2ndquadrant(dot)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. Do
let me know if you think otherwise or if you have better ideas? We can
think of improving the code as a separate patch if we think it is
important.

[1] - https://www.postgresql.org/message-id/CAA4eK1Km5VVmdPpdMNSA414uRFJKVw8r_A7ORpL-0pHnYfGpLw%40mail.gmail.com

--
With Regards,
Amit Kapila.