Re: d25ea01275 and partitionwise join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Richard Guo <riguo(at)pivotal(dot)io>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: d25ea01275 and partitionwise join
Date: 2020-04-06 14:09:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Mon, Apr 6, 2020 at 7:29 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2020-04-06 14:28:14 Re: WAL usage calculation patch
Previous Message Anastasia Lubennikova 2020-04-06 13:49:31 Re: pg_upgrade fails with non-standard ACL