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

From Amit Langote
Subject Re: d25ea01275 and partitionwise join
Date
Msg-id CA+HiwqEiD6ZTgmO1-iJ00JRq4XSjVaCEe1xZRnaeZJF9smZfzw@mail.gmail.com
Whole thread Raw
In response to Re: d25ea01275 and partitionwise join  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 8, 2020 at 11:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Thank you for your time on this.

-- 

Amit Langote
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

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