Re: [HACKERS] Block level parallel vacuum - Mailing list pgsql-hackers

On Wed, 6 Nov 2019 at 18:42, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh <mahi6run@gmail.com> wrote:
> >
> > Hi
> > I took all attached patches(v32-01 to v32-4) and one Dilip's patch from "Questions/Observations related to Gist
vacuum"mail thread. On the top of all these patches, I created one more patch to test parallel vacuum functionally for
allexistence test suite. 

Thank you for looking at this patch!

> > For reference, I am attaching patch.
> >
> > What does this patch?
> > As we know that if we give parallel option with vacuum, then only we are vacuuming using parallel workers. So to
test,I used existence guc force_parallel_mode and tested parallel vacuuming. 
> >
> > If force_parallel_mode is set as regress, then if parallel option is not given with vacuum, I am forcing to use
parallelworkers for vacuum. If there is only one index and parallel degree is not given with vacuum(or parallel option
isnot given), and force_parallel_mode = regress, then I am launching one parallel worker(I am not doing work by leader
inthis case), but if there is more than one index, then i am using leader as a worker for one index and launching
workersfor all other indexes. 
> >
> > After applying this patch and setting force_parallel_mode = regress, all test cases are passing (make-check world)
> >
> > I have some questions regarding my patch. Should we do vacuuming using parallel workers even if force_parallel_mode
isset as on, or we should use new GUC to test parallel worker vacuum for existence test suite? 
>
> IMHO, with force_parallel_mode=on we don't need to do anything here
> because that is useful for normal query parallelism where if the user
> thinks that the parallel plan should have been selected by the planer
> but planer did not select the parallel plan then the user can force
> and check.  But, vacuum parallelism is itself forced by the user so
> there is no point in doing it with force_parallel_mode=on.

Yeah I think so too. force_parallel_mode is a planner parameter and
parallel vacuum can be forced by vacuum option.

>  However,
> force_parallel_mode=regress is useful for testing the vacuum with an
> existing test suit.

If we want to control the leader participation by GUC parameter I
think we would need to have another GUC parameter rather than using
force_parallel_mode. And it's useful if we can use the parameter for
parallel CREATE INDEX as well. But it should be a separate patch.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services