Re: [HACKERS] Rethinking behavior of force_parallel_mode = regress

2016-06-24 Thread Robert Haas
On Tue, Jun 21, 2016 at 4:41 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane wrote: >>> With that thought in mind, I propose that the behavior of >>> force_parallel_mode = regress is ill-designed so far as EXPLAIN is >>> concerned. What it ought to do is s

Re: [HACKERS] Rethinking behavior of force_parallel_mode = regress

2016-06-21 Thread Tom Lane
Robert Haas writes: > On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane wrote: >> With that thought in mind, I propose that the behavior of >> force_parallel_mode = regress is ill-designed so far as EXPLAIN is >> concerned. What it ought to do is suppress *all* Gathers from the output, >> not just ones

Re: [HACKERS] Rethinking behavior of force_parallel_mode = regress

2016-06-21 Thread Robert Haas
On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane wrote: > As of HEAD it is possible to get through all of our regression tests > with these settings: > > alter system set force_parallel_mode = regress; > alter system set max_parallel_workers_per_gather = 2; > alter system set parallel_tuple_cost = 0; > a