On Wed, 6 Nov 2019 at 18:42, Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Wed, Nov 6, 2019 at 2:01 PM Mahendra Singh <mahi6...@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 all existence 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 parallel workers for vacuum. If > > there is only one index and parallel degree is not given with vacuum(or > > parallel option is not given), and force_parallel_mode = regress, then I am > > launching one parallel worker(I am not doing work by leader in this case), > > but if there is more than one index, then i am using leader as a worker for > > one index and launching workers for 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 is set 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
