Simon Riggs <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
