From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Elvis Pranskevichus <elprans(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize |
Date: | 2021-10-05 01:59:40 |
Message-ID: | CAApHDvru_idyPg4PvYk3HVnhiHwHq1uHe5YCfnaFD2GWGHyUEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 5 Oct 2021 at 14:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Elvis Pranskevichus <elprans(at)gmail(dot)com> writes:
> > On Monday, October 4, 2021 5:14:47 PM PDT David Rowley wrote:
> >>> It appears a combination of Merge Semi Join and Memoize in
> >>> PostgreSQL 14 produces incorrect results on a particular query.
>
> > It seems like a very particular set of stats is causing the plan there,
> > as running ANALYZE turns the query into a Nested Loop Semi Join.
>
> Surely this plan tree is broken on its face? The inner side of
> a mergejoin has to be able to support mark/restore, and nestloop
> doesn't (cf ExecSupportsMarkRestore, as well as assertions in
> nodeNestloop). It looks to me like somebody removed an essential
> plan-time check.
Couldn't that just be because it's a Merge Semi Join and there's not
really any need to rewind the inner side if all join clauses are merge
join clauses, aka:
if ((path->jpath.jointype == JOIN_SEMI ||
path->jpath.jointype == JOIN_ANTI ||
extra->inner_unique) &&
(list_length(path->jpath.joinrestrictinfo) ==
list_length(path->path_mergeclauses)))
path->skip_mark_restore = true;
?
David
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-10-05 03:19:02 | Re: BUG #17212: pg_amcheck fails on checking temporary relations |
Previous Message | Tom Lane | 2021-10-05 01:21:21 | Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize |