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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: GiST a second class citizen?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Read-only plan trees