Amit Langote <amitlangot...@gmail.com> writes:
> On Mon, Apr 6, 2020 at 7:29 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> * I think your logic for building the coalesce combinations was just
>> wrong. We need combinations of left-hand inputs with right-hand inputs,
>> not left-hand with left-hand or right-hand with right-hand. Also the
>> nesting should already have happened in the inputs, we don't need to
>> try to generate it here. The looping code was pretty messy as well.
> It didn't occur to me that that many Coalesce combinations would be
> necessary given the component rel combinations possible.
Well, we don't of course: we only need the one pair that corresponds to
the COALESCE structures the parser would have generated. But we aren't
sure which one that is. I thought about looking through the full join
RTE's joinaliasvars list for COALESCE items instead of doing it like this,
but there is a problem: I don't believe that that data structure gets
maintained after flatten_join_alias_vars(). So it might contain
out-of-date expressions that don't match what we need them to match.
Possibly there will be a cleaner answer here if I succeed in redesigning
the Var data structure to account for outer joins better.
>> * I did not follow the point of your second test case. The WHERE
>> constraint on p1.a allows the planner to strength-reduce the joins,
>> which is why there's no full join in that explain result, but then
>> we aren't going to get to this code at all.
> Oops, I thought I copy-pasted 4-way full join test not this one, but
> evidently didn't.
Have you got such a query at hand? I wondered whether we shouldn't
use a 4-way rather than 3-way test case; it'd offer more assurance
that nesting of these things works.
regards, tom lane
