Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> Either of these approaches would mean that we couldn't easily "just
>> execute" a scalar expression tree, which is something that we do in
>> quite a few places (constraint checking for instance). There would need
>> to be some advance setup done. With the Param-style approach, the
>> advance setup would not be read-only on the expression plan tree ...
>> which seems like a bad idea, so I'm leaning towards building the more
>> expensive data structure.
> Even though the former is a bit more expensive, it sounds like it is still a
> net win due to reduced/eliminated need for making plan tree copies,
> right?
I think it will be a net win compared to our current code, because we
can save copying whole plan trees in a number of places. But I was
wondering if further improvement is possible.
Another reason not to go with the fcache-array approach is that it does not
help with storing executor-state data for anything except op/func nodes.
I am not sure offhand whether we need any for other expression node
types, but it's sure a reasonably likely future possibility.
> Sounds like a great plan. Let me know if there's anything I can do to help.
Right at the moment I'm struggling a bit with terminology. We've got
basically four categories of node types to deal with in this scheme:
Plan steps Expressions (Scan, Sort, etc) (Var, Op, Func, etc)
Planner output "Plan" "Expr"?
Executor state "CommonState" ???
The existing Plan-category nodes are all derived from nodetype Plan,
so that seems reasonably well set. The existing executor state nodes
for Plan nodes are all derived from CommonState, but that seems like
a name that conveys hardly anything. The existing expression-category
nodes do *not* have any common substructure, and don't seem to need any.
I'm not thrilled about using Expr as a generic term for them, but am not
sure what else to write. (I'm also finding it confusing whether "plan
node" means "any node in a tree output by the planner" --- which would
then include expression nodes --- or just nodes that correspond to major
steps in the query pipeline --- which is the present usage.) And what
about a generic term for execution state nodes for expression nodes?
Any ideas about naming are welcome.
regards, tom lane
