Re: Rethinking behavior of force_parallel_mode = regress

On Tue, Jun 21, 2016 at 4:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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