Re: mark/restore failures on unsorted merge joins

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)