public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Richard Guo <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Finnerty, Jim <[email protected]>
Subject: Re: Making Vars outer-join aware
Date: Wed, 28 Dec 2022 10:36:46 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAMbWs4_JDDdXvEBWtTao9ZTwOGdDCU7X-=bF7yi9G1u_-b0Dfw@mail.gmail.com>
References: <[email protected]>
<CAMbWs49KZO2VvMqo+1MQfaX4cun7vhF=5RgVdpA0gjJcj77HFQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAMbWs4-0cdVpgY0c2uULBCX2vPjQt3Fx3=XFZh-Mn=UWmxhG-A@mail.gmail.com>
<[email protected]>
<CAMbWs4_va6UWcaiPSZpeRPFzpA=UKU+4zKkxqdfrcKoKA5nKWA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAMbWs480igxj6hTbvD0WEnzT4XJ8hJXg71EVJO_BcQqN90MQuA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CAMbWs498oYx4pjzOsjxu0wG0D73e2+OFAqkbPotcSJDKzm-s4Q@mail.gmail.com>
<[email protected]>
<CAMbWs4-mvPPCJ1W6iK6dD5HiNwoJdi6mZp=-7mE8N9Sh+cd0tQ@mail.gmail.com>
<CAMbWs4_WNcvQGiFMLJanj3h6WMzFi6P-=bifmnuXUcg4PSXQgA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAMbWs4_pH7w7voY0AejUM4RiKq-Xuf+sXmoF8PcQwzNrsagEXA@mail.gmail.com>
<275580! [email protected]>
<CAMbWs4_gXgGdkkOraUPEoZD_Q3xTW7FTxfomW+fxPN2Kr-YSXg@mail.gmail.com>
<[email protected]>
<CAMbWs4_JDDdXvEBWtTao9ZTwOGdDCU7X-=bF7yi9G1u_-b0Dfw@mail.gmail.com>
Richard Guo <[email protected]> writes:
> I think I see where the problem is. And I can see currently in
> get_eclass_for_sort_expr we always use the top JoinDomain. So although
> the equality clause 'a.x = b.y' belongs to JoinDomain {B}, we set up ECs
> for 'a.x' and 'b.y' that belong to the top JoinDomain {A, B, A/B}.
Yeah, that's a pretty squishy point, and likely wrong in detail.
If we want to associate an EC with the sort order of an index on
b.y, we almost certainly want that EC to belong to join domain {B}.
I had tried to do that in an earlier iteration of 0012, by dint of
adding a JoinDomain argument to get_eclass_for_sort_expr and then
having build_index_pathkeys specify the lowest join domain containing
the index's relation. It did not work very well: it couldn't generate
mergejoins on full-join clauses, IIRC.
Maybe some variant on that plan can be made to fly, but I'm not at
all clear on what needs to be adjusted. Anyway, that's part of why
I backed off on the notion of explicitly associating ECs with join
domains. As long as we only pay attention to the join domain in
connection with constants, get_eclass_for_sort_expr can get away with
just using the top join domain, because we'd never apply it to a
constant unless perhaps somebody manages to ORDER BY or GROUP BY a
constant, and in those cases the top domain really is the right one.
(It's syntactically difficult to write such a thing anyway, but not
impossible.)
I think this is sort of an intermediate state, and hopefully a
year from now we'll have a better idea of how to manage all that.
What I mainly settled for doing in 0012 was getting rid of the
"below outer join" concept for ECs, because having to identify
a value for that had been giving me fits in several previous
attempts at extending ECs to cover outer-join equalities.
I think that the JoinDomain concept will offer a better-defined
replacement.
regards, tom lane
view thread (42+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Making Vars outer-join aware
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox