On 26 March 2017 at 00:17, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sat, Mar 25, 2017 at 6:31 PM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> On 25 March 2017 at 23:09, Rushabh Lathia <rushabh.lat...@gmail.com> wrote: >>> Also another point which I think we should fix is, when someone set >>> max_parallel_workers = 0, we should also set the >>> max_parallel_workers_per_gather >>> to zero. So that way it we can avoid generating the gather path with >>> max_parallel_worker = 0. >> >> I see that it was actually quite useful that it works the way it does. >> If it had worked the same as max_parallel_workers_per_gather, then >> likely Tomas would never have found this bug. >> >> I wondered if there's anything we can do here to better test cases >> when no workers are able to try to ensure the parallel nodes work >> correctly, but the more I think about it, the more I don't see wrong >> with just using SET max_parallel_workers = 0; >> >> My vote would be to leave the GUC behaviour as is and add some tests >> to select_parallel.sql which exploit setting max_parallel_workers to 0 >> for running some tests. >> > > I think force_parallel_mode=regress should test the same thing.
Not really. That flag's days are surely numbered. It creates a Gather node, the problem was with GatherMerge. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers