On Tue, Jun 21, 2016 at 4:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane <t...@sss.pgh.pa.us> 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 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. > > Well, sure, but in those areas you just set force_parallel_mode to on.
Well, I don't see how that gets you anywhere. Now every regression test that generates a parallel plan needs a decoration to set force_parallel_mode=on temporarily and then change it back to regress afterwards. And once you've done that, you no longer get any benefit out of having changed the behavior of force_parallel_mode=regress. Either I need more caffeine, or this is a bad plan. Possibly both, because I definitely need more caffeine. >> The charter of force_parallel_mode=regress >> is that any regression test that passes normally should still pass >> with that setting. > > I would like that charter to include scenarios with other nondefault GUC > settings, to the extent we can reasonably make it work, because setting > *only* force_parallel_mode is pretty sad in terms of test coverage. > Or hadn't you noticed all the bugs we flushed from cover as soon as we > tried changing the cost values? Well, I did send a WIP patch to set consider_parallel correctly for upper rels, which helps a lot, but you seem not to have looked at it. I think we should fix the bugs in the current approach before deciding that it doesn't work. That having been said, I can't disagree with the principle you're setting forth here. -- 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
