Re: Scrollable cursors and Sort performance

Simon Riggs <simon@2ndquadrant.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