Re: d25ea01275 and partitionwise join - Mailing list pgsql-hackers

From Tom Lane
Subject Re: d25ea01275 and partitionwise join
Date
Msg-id 6089.1586312221@sss.pgh.pa.us
Whole thread Raw
In response to Re: d25ea01275 and partitionwise join  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: d25ea01275 and partitionwise join  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Re: d25ea01275 and partitionwise join  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes:
> On Tue, Apr 7, 2020 at 2:41 AM Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgsql: Allow users to limit storage reserved by replication slots
Next
From: Michael Paquier
Date:
Subject: Re: implicit declaration of datumIsEqual in parse_coerce.c