2014-07-18 10:28 GMT+09:00 Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> > I haven't followed this at all, but I just skimmed over it and noticed
>> > the CustomPlanMarkPos thingy; apologies if this has been discussed
>> > before. It seems a bit odd to me; why isn't it sufficient to have a
>> > boolean flag in regular CustomPlan to indicate that it supports
>> > mark/restore?
>>
>> Yeah, I thought that was pretty bogus too, but it's well down the list of
>> issues that were there last time I looked at this ...
>>
> IIRC, CustomPlanMarkPos was suggested to keep the interface of
> ExecSupportsMarkRestore() that takes plannode tag to determine
> whether it support Mark/Restore.
> As my original proposition did, it seems to me a flag field in
> CustomPlan structure is straightforward, if we don't hesitate to
> change ExecSupportsMarkRestore().
>
The attached patch revised the above point.
It eliminates CustomPlanMarkPos, and adds flags field on CustomXXX
structure to inform the backend whether the custom plan provider can
support mark-restore position and backward scan.
This change requires ExecSupportsMarkRestore() to reference
contents of Path node, not only node-tag, so its declaration was also
changed to take a pointer to Path node.
The only caller of this function is final_cost_mergejoin() right now.
It just gives pathtype field of Path node on its invocation, so this change
does not lead significant degradation.
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>