Re: Read-only plan trees
От | Joe Conway |
---|---|
Тема | Re: Read-only plan trees |
Дата | |
Msg-id | 3DEAC41A.4070002@joeconway.com обсуждение исходный текст |
Ответ на | Re: Read-only plan trees (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Read-only plan trees
|
Список | pgsql-hackers |
Tom Lane wrote: > 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. Maybe: Plan steps Expressions ----------------- -------------------- Planner output "Plan" "Expr" Executor state "PlanState" "ExprState" I think "Plan node" should only refer to nodes literally derived from nodetype Plan. Similarly with "PlanState nodes". Joe
В списке pgsql-hackers по дате отправления: