Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize
От | David Rowley |
---|---|
Тема | Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize |
Дата | |
Msg-id | CAApHDvru_idyPg4PvYk3HVnhiHwHq1uHe5YCfnaFD2GWGHyUEw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Tue, 5 Oct 2021 at 14:21, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Elvis Pranskevichus <elprans@gmail.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
В списке pgsql-bugs по дате отправления: