Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers

On Thu, Oct 15, 2020 at 9:02 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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.
>

Pushed.

--
With Regards,
Amit Kapila.