From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Wrong results with right-semi-joins |
Date: | 2024-12-11 02:27:00 |
Message-ID: | CAMbWs4-ZiYNco_+jQ3rWnAzA2qOE44boc7kqrj_eJ=_YECRubw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 9, 2024 at 11:01 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> Thanks for finding and fixing this. Just for my own benefit, could you
> explain more about the minimal repro? Specifically, if you just need a
> subplan in the hash side of a right semi-join, why do you also need
> the outer part of the query that produces the initplan?
>
> Seq Scan on tbl_rs t1
> Filter: ((SubPlan 3) >= 0)
> SubPlan 3
> -> Limit
> InitPlan 2
> -> Hash Right Semi Join
Upon further consideration, I believe the initplan is unnecessary.
What we really want from the plan is to reuse the hash table during
hash-right-semi-join rescans. To achieve this, we just need to ensure
that it's a single-batch join and that there are no parameter changes
on the inner side.
I spent some time on this and came up with a simpler query to
reproduce the issue.
explain (costs off)
select * from tbl_rs t1 join
lateral (select * from tbl_rs t2 where t2.a in
(select t1.a+t3.a from tbl_rs t3) and t2.a < 5)
on true;
QUERY PLAN
-------------------------------------------
Nested Loop
-> Seq Scan on tbl_rs t1
-> Hash Right Semi Join
Hash Cond: ((t1.a + t3.a) = t2.a)
-> Seq Scan on tbl_rs t3
-> Hash
-> Seq Scan on tbl_rs t2
Filter: (a < 5)
(8 rows)
Without the fix, this query returns 3 rows rather than the expected 6.
Maybe I should update the test case introduced in 5668a857d to this
one.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2024-12-11 02:34:29 | RE: Parallel heap vacuum |
Previous Message | Zhijie Hou (Fujitsu) | 2024-12-11 02:13:50 | RE: Memory leak in WAL sender with pgoutput (v10~) |