Re: Oddity with parallel safety test for scan/join target in grouping_planner - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Oddity with parallel safety test for scan/join target in grouping_planner
Date
Msg-id 1962.1552281261@sss.pgh.pa.us
Whole thread Raw
In response to Re: Oddity with parallel safety test for scan/join target in grouping_planner  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Oddity with parallel safety test for scan/join target in grouping_planner
List 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 by date:

Previous
From: amul sul
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Next
From: Etsuro Fujita
Date:
Subject: Re: Oddity with parallel safety test for scan/join target in grouping_planner