>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> 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.) Tom> 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? Tom> Uh, why would you not just look to see if the ammarkpos/amrestrpos Tom> fields are non-null? We don't (in the back branches) seem to have a pointer to the IndexAmRoutine handy, only the oid? Obviously we can look it up from the oid, but is that more overhead than we want in a join cost function, given that this will be called for all potential mergejoins considered, not just JOIN_FULL? Or is the overhead not worth bothering about? -- Andrew (irc:RhodiumToad)
