Re: Scrollable cursors and Sort performance

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Sun, 2006-02-26 at 19:26 -0500, Tom Lane wrote:
>> After looking at my old notes about Materialize,
>> I am thinking that we should add a "int flags" parameter to the InitNode
>> calls along with ExecutorStart and probably PortalStart.

> Design-wise I was looking at putting a named struc in there, so it would
> be easily expandible in the future to carry anything else that needs to
> be passed down through the nodes like this.

That would be the hard way, primarily because it would require copying
and modifying the struct at each level of recursion --- which'd turn
what should be a nearly zero-cost patch into something with possibly
nontrivial cost.

Copy and modify is needed because as one descends through the plan tree
the requirements change. For instance, MergeJoin requires mark/restore
capability of its right input, but this will never be a requirement
propagated from the top (or anyplace else). Materialize on the other
hand should turn off some of the bits, since it won't pass backwards
scan or mark/restore calls down to its child. These are trivial changes
to implement with a flag-word representation, not so with a struct.

If I saw a need for non-boolean parameters in this structure then maybe
I'd agree, but there's no evidence of a need for them. What the child
plan nodes need to know is "will I get any mark/restore calls" and such
like, and those are certainly boolean conditions.

I'm envisioning coding like

ExecInitMergeJoin(MergeJoin *node, EState *estate, int flags)
...
/* reject unsupported cases */
Assert(!(flags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)));
...
innerPlanState(mergestate) = ExecInitNode(innerPlan(node),
estate,
flags | EXEC_FLAG_MARK);

nodeSort.c would have a test like

node->random = (flags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)) != 0;

etc etc.

regards, tom lane