public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Hans Buschmann <[email protected]>
Cc: Richard Guo <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Finnerty, Jim <[email protected]>
Subject: Re: Making Vars outer-join aware
Date: Tue, 24 Jan 2023 15:25:42 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwbnG8J+xDaS310r0Nszk9-e5DBQzfqUN6HFdvUO17BKSw@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>
<CAMbWs! [email protected]>
<[email protected]>
<CAMbWs4_JDDdXvEBWtTao9ZTwOGdDCU7X-=bF7yi9G1u_-b0Dfw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAKFQuwbnG8J+xDaS310r0Nszk9-e5DBQzfqUN6HFdvUO17BKSw@mail.gmail.com>
"David G. Johnston" <[email protected]> writes:
> On Tue, Jan 24, 2023 at 12:31 PM Tom Lane <[email protected]> wrote:
>> select ... from t1 left join t2 on (t1.x = t2.y and t1.x = 1);
>>
>> If we turn the generic equivclass.c logic loose on these clauses,
>> it will deduce t2.y = 1, which is good, and then apply t2.y = 1 at
>> the scan of t2, which is even better (since we might be able to turn
>> that into an indexscan qual). However, it will also try to apply
>> t1.x = 1 at the scan of t1, and that's just wrong, because that
>> will eliminate t1 rows that should come through with null extension.
> Is there a particular comment or README where that last conclusion is
> explained so that it makes sense.
Hm? It's a LEFT JOIN, so it must not eliminate any rows from t1.
A row that doesn't have t1.x = 1 will appear in the output with
null columns for t2 ... but it must still appear, so we cannot
filter on t1.x = 1 in the scan of t1.
regards, tom lane
view thread (2+ 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], [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