Re: Rethinking behavior of force_parallel_mode = regress - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rethinking behavior of force_parallel_mode = regress
Date
Msg-id 18407.1466541695@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rethinking behavior of force_parallel_mode = regress  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Rethinking behavior of force_parallel_mode = regress  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane <tgl@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.

> 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?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Rethinking behavior of force_parallel_mode = regress
Next
From: Michael Paquier
Date:
Subject: Re: Requesting external_pid_file with postgres -C when not initialized lead to coredump