Re: Oddity with parallel safety test for scan/join target in grouping_planner

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Oddity with parallel safety test for scan/join target in grouping_planner
Дата
Msg-id 32401.1552277190@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Oddity with parallel safety test for scan/join target in grouping_planner  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Ответы Re: Oddity with parallel safety test for scan/join target in grouping_planner
Список pgsql-hackers
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
>>> The parallel safety of the final scan/join target is determined from the
>>> grouping target, not that target, which [ is wrong ]

> This would only affect plan quality a little bit, so I don't think we 
> need a regression test for this, either, but the fix might destabilize 
> existing plan choices, so we should apply it to HEAD only?

Is that the only possible outcome?  Per Robert's summary quoted above,
it seems like it might be possible for the code to decide that the final
scan/join target to be parallel safe when it is not, leading to outright
wrong answers or query failures.  If the wrong answer can only be wrong
in the safe direction, it's not very clear why.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Should we add GUCs to allow partition pruning to be disabled?
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Should we add GUCs to allow partition pruning to be disabled?