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:

Reply via email to