Re: mark/restore failures on unsorted merge joins
От | Tom Lane |
---|---|
Тема | Re: mark/restore failures on unsorted merge joins |
Дата | |
Msg-id | 125707.1606161260@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | mark/restore failures on unsorted merge joins (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: mark/restore failures on unsorted merge joins
|
Список | pgsql-hackers |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > The problem is that the planner calls ExecSupportsMarkRestore to find > out whether a Materialize node is needed, and that function looks no > further than the Path type of T_Index[Only]Path in order to return true, > even though in this case it's a GiST index which does not support > mark/restore. > (Usually this can't be a problem because the merge join would need > sorted input, thus the index scan would be a btree; but a merge join > that doesn't actually have any sort keys could take unsorted input from > any index type.) Sounds like the right analysis. > Going forward, this looks like IndexOptInfo needs another am* boolean > field, but that's probably not appropriate for the back branches; maybe > as a workaround, ExecSupportsMarkRestore should just check for btree? Uh, why would you not just look to see if the ammarkpos/amrestrpos fields are non-null? regards, tom lane
В списке pgsql-hackers по дате отправления: