Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Looks about right. Not sure if we need to bother with a regression
> Tom> test case; once that's in, it'd be hard to break it.
> We could check the EXPLAIN output (since the Materialize node would show
> up), but it's not easy to get sta
> "Tom" == Tom Lane writes:
>> I guess that's close enough; this should suffice then.
Tom> Looks about right. Not sure if we need to bother with a regression
Tom> test case; once that's in, it'd be hard to break it.
We could check the EXPLAIN output (since the Materialize node would show
Andrew Gierth writes:
> I guess that's close enough; this should suffice then.
Looks about right. Not sure if we need to bother with a regression test
case; once that's in, it'd be hard to break it.
regards, tom lane
> "Tom" == Tom Lane writes:
Tom> Oh, sorry, I misread your comment to be that you wanted to add a
Tom> field to IndexAmRoutine. You're right, the real issue here is that
Tom> ExecSupportsMarkRestore lacks any convenient access to the needed
Tom> info, and we need to add a bool to IndexOpt
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> 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?
Oh, sorry, I misread your comment to be
> "Tom" == Tom Lane 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
Andrew Gierth 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 no
