Message-ID: <a4c47fcd-e3c9-41ca-8520-51bb01cde536@gmail.com>
Date: Fri, 12 Jul 2024 06:49:34 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: inequality predicate not pushed down in JOIN?
To: Paul George <p.a.george19@gmail.com>,
 pgsql-performance@lists.postgresql.org
References: 
 <CALA8mJr2zKNBMqD=f-Ts-2CYtOUyvFJ7Z2wQVe3wkOnqZL1BJw@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CALA8mJr2zKNBMqD=f-Ts-2CYtOUyvFJ7Z2wQVe3wkOnqZL1BJw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/a4c47fcd-e3c9-41ca-8520-51bb01cde536%40gmail.com>
Precedence: bulk

On 12/7/2024 06:31, Paul George wrote:
> In the example below, I noticed that the JOIN predicate "t1.a<1" is not 
> pushed down to the scan over "t2", though it superficially seems like it 
> should be.
It has already discussed at least couple of years ago, see [1].
Summarising, it is more complicated when equivalences and wastes CPU 
cycles more probably than helps.

> 
> create table t as (select 1 a);
> analyze t;
> explain (costs off) select * from t t1 join t t2 on t1.a=t2.a and t1.a<1;
>            QUERY PLAN
> -------------------------------
>   Hash Join
>     Hash Cond: (t2.a = t1.a)
>     ->  Seq Scan on t t2
>     ->  Hash
>           ->  Seq Scan on t t1
>                 Filter: (a < 1)
> (6 rows)
> 
> The same is true for the predicate "t1.a in (0, 1)". For comparison, the 
> predicate "t1.a=1" does get pushed down to both scans.
> 
> explain (costs off) select * from t t1 join t t2 on t1.a=t2.a and t1.a=1;
>         QUERY PLAN
> -------------------------
>   Nested Loop
>     ->  Seq Scan on t t1
>           Filter: (a = 1)
>     ->  Seq Scan on t t2
>           Filter: (a = 1)
> (5 rows)

[1] Condition pushdown: why (=) is pushed down into join, but BETWEEN or 
 >= is not?
https://www.postgresql.org/message-id/flat/CAFQUnFhqkWuPCwQ1NmHYrisHJhYx4DoJak-dV%2BFcjyY6scooYA%40mail.gmail.com

-- 
regards, Andrei Lepikhov