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 32401.1552277190@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:
>>> 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?
Next
From: Justin Pryzby
Date:
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?