Re: Rethinking behavior of force_parallel_mode = regress

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rethinking behavior of force_parallel_mode = regress
Дата
Msg-id 18407.1466541695@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rethinking behavior of force_parallel_mode = regress  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Rethinking behavior of force_parallel_mode = regress  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Rethinking behavior of force_parallel_mode = regress
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Requesting external_pid_file with postgres -C when not initialized lead to coredump