From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Paul George <p(dot)a(dot)george19(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: inequality predicate not pushed down in JOIN? |
Date: | 2024-07-11 23:49:34 |
Message-ID: | a4c47fcd-e3c9-41ca-8520-51bb01cde536@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul George | 2024-07-12 00:07:05 | Re: inequality predicate not pushed down in JOIN? |
Previous Message | Paul George | 2024-07-11 23:31:24 | inequality predicate not pushed down in JOIN? |