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 1962.1552281261@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:
> (2019/03/11 13:06), Tom Lane wrote:
>> 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.

> Maybe I'm missing something, but I think that if the final scan/join 
> target is not parallel-safe, then the grouping target would not be 
> parallel-safe either, by the construction of the two targets, so I don't 
> think that we have such a correctness issue.

Seems to me it's the other way around: the final target would include
all functions invoked in the grouping target plus maybe some more.
So a non-parallel-safe grouping target implies a non-parallel-safe
final target, but not vice versa.

Possibly the summary had it backwards and the actual code bug is
inferring things in the safe direction, but I'm too tired to double
check that right now ...

            regards, tom lane


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

Предыдущее
От: amul sul
Дата:
Сообщение: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Oddity with parallel safety test for scan/join target in grouping_planner