On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane <t...@sss.pgh.pa.us> 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; > alter system set parallel_setup_cost = 0; > alter system set min_parallel_relation_size = 0; > > although there are quite a number of cosmetic differences in the outputs > for the core regression tests. (Curiously, contrib, pl, and isolation > seem to pass without any diffs.) In view of the number of bugs we've been > able to identify with this setup, it would be nice to reduce the volume of > the cosmetic differences to make it easier to review the diffs by hand. > I'm not sure there's much that can be done about the row-ordering diffs; > some randomness in the output order from a parallel seqscan seems > inevitable. But we could tamp down the EXPLAIN output differences, which > are much harder to review anyway. > > 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 that were added in response to force_parallel_mode itself.
No, that doesn't sound like a very good idea. If you do that, then you have no hope of the differences being *zero*, because any place that the regression tests are intended to produce a parallel plan is going to look different. The charter of force_parallel_mode=regress is that any regression test that passes normally should still pass with that setting. This change would clearly break that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
