From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Antti Lampinen <antti(at)lampinen(dot)eu> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18522: Wrong results with Merge Right Anti Join, inconsistent with Merge Anti Join |
Date: | 2024-06-25 14:45:59 |
Message-ID: | CAMbWs4_ocgBk_XHQmy5VMiHofgQt1upqeY36RKsjCE8pK8DHqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Jun 25, 2024 at 7:54 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> Thank you so much for the repro script. I've found the root cause:
> for an inner_unique join we assume that the executor will stop scanning
> for matches after the first match. Therefore, we set skip_mark_restore
> to true to indicate that we can skip mark/restore overhead. However,
> merge right anti join does not get this memo and continues scanning the
> inner side for matches after the first match, totally ignoring the
> single_match flag, while still thinking that it can skip mark/restore.
>
> Will fix this later.
I think we can fix this issue by ensuring that merge-right-anti-join
also advances to next outer tuple after the first match in inner_unique
cases. This can also help save cycles by avoiding unnecessary scanning
of inner tuples after the first match.
Although hash-right-anti-join does not suffer from this wrong results
issue, I think we can apply the same change to it as well, to help save
cycles for the same reason.
Please see attached patch for the fix. This patch still lacks a test
case. I'll try to see if I can come up with one.
Thanks
Richard
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Fix-right-anti-joins-when-the-inner-relation-is-proven-unique.patch | application/octet-stream | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-06-25 19:37:40 | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae |
Previous Message | Richard Guo | 2024-06-25 11:54:25 | Re: BUG #18522: Wrong results with Merge Right Anti Join, inconsistent with Merge Anti Join |