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 Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: d25ea01275 and partitionwise join
Date: 2020-04-08 02:17:01
Message-ID: 6089.1586312221@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Tue, Apr 7, 2020 at 2:41 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I *think* that it might be all right, because although what we
>> are matching to is a user-written COALESCE() not an actual
>> FULL JOIN USING column, it has to behave in somewhat the same
>> way. In particular, by construction it must be a coalesce of
>> some representation of the matching partition columns of the
>> full join's inputs. So, even though it might go to null in
>> different cases than an actual USING variable would do, it
>> does not break the ability to partition the join.

> Seems fine to me too. Maybe users should avoid writing it by hand if
> possible anyway, because even slight variation in the way it's written
> will affect this:

I'm not particularly concerned about users intentionally trying to trigger
this behavior. I just want to be sure that if someone accidentally does
so, we don't produce a wrong plan.

I waited till after the "advanced partitionwise join" patch went
in because that seemed more important (plus I wondered a bit if
that would subsume this). But this patch seems to still work,
and the other thing doesn't fix the problem, so pushed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-04-08 02:23:45 Re: [BUG] non archived WAL removed during production crash recovery
Previous Message Andres Freund 2020-04-08 02:10:07 Re: pgsql: Allow users to limit storage reserved by replication slots