Обсуждение: How to look at the Expression Trees

Поиск
Список
Период
Сортировка

How to look at the Expression Trees

От
Vaibhav Kaushal
Дата:
Hi all,

I have been trying to work on the expression evaluator (trying to alter
it just for the seqscan case). I have understood a few things. I wish
someone could tell me if I am wrong at some point. As far as I have gone
through the code, I think:

1. Quals are formulated by planner
2. Quals are actually a list of Expression Trees.
3. They are created in the ExecInitExpr function.
4. Every row / tuple table slot is run through the same qual list and
thus goes through the same expression tree execution path as the other
(of course being filtered in between if they do not fit the qual in the
list). 

5. The most common nodes in the expression trees are the ExecEvalVar,
ExecEvalConst and ExecEvalParam.

I might be wrong somewhere (especially most people would be able to say
a lot about the 5th point). But if the above were to be correct then how
and why are the ExecMakeFunctionResultNoSets, ExecEvalRelabelType,
ExecEvalFuncArgs and the likes are used?

I wanted to see how the expression tree gets into form before it gets
into the ExecQual for parse by ExecEvalExpr function. Is there a way to
see the Expression Tree so that I get a better idea about what is
happening?

Regards,
Vaibhav 




Re: How to look at the Expression Trees

От
Heikki Linnakangas
Дата:
On 21.03.2011 13:44, Vaibhav Kaushal wrote:
> Hi all,
>
> I have been trying to work on the expression evaluator (trying to alter
> it just for the seqscan case). I have understood a few things. I wish
> someone could tell me if I am wrong at some point. As far as I have gone
> through the code, I think:
>
> 1. Quals are formulated by planner
> 2. Quals are actually a list of Expression Trees.
> 3. They are created in the ExecInitExpr function.
> 4. Every row / tuple table slot is run through the same qual list and
> thus goes through the same expression tree execution path as the other
> (of course being filtered in between if they do not fit the qual in the
> list).

Yes. There's actually two "trees" involved. The planner produces a tree 
of Expr nodes, and ExecInitExpr prepares a tree of ExprState nodes that 
mirrors the first tree. The ExprStates contain run-time state needed to 
execute the Expr tree.

> 5. The most common nodes in the expression trees are the ExecEvalVar,
> ExecEvalConst and ExecEvalParam.

Well, that's obviously going to depend on the query.

> I might be wrong somewhere (especially most people would be able to say
> a lot about the 5th point). But if the above were to be correct then how
> and why are the ExecMakeFunctionResultNoSets, ExecEvalRelabelType,
> ExecEvalFuncArgs and the likes are used?

ExecMakeFunctionResultNoSets is used to evaluate function calls. The 
first function call invocation always uses ExecMakeFunctionResult, but 
if ExecMakeFunctionResult sees on that first invocation that it was not 
a set-returning-function, it changes the evaluator function for 
subsequent invocations to ExecMakeFunctionResultNoSets. 
ExecMakeFunctionResultNoSets does the same thing as 
ExecMakeFunctionResult, but skips the checks for set-returning 
functions, making the evaluation a bit faster.

ExecEvalFuncArgs is used by ExecMakeFunctionResult to evaluate the 
function arguments.

ExecEvalRelabelType is used to evaluate RelabelType nodes. RelabelType 
doesn't really do anything, it's just a placeholder when a type is cast 
to another, and the source and target types are binary compatible.

> I wanted to see how the expression tree gets into form before it gets
> into the ExecQual for parse by ExecEvalExpr function. Is there a way to
> see the Expression Tree so that I get a better idea about what is
> happening?

set debug_print_plan=on

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: How to look at the Expression Trees

От
Vaibhav Kaushal
Дата:


On Mon, Mar 21, 2011 at 5:47 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:

Yes. There's actually two "trees" involved. The planner produces a tree of Expr nodes, and ExecInitExpr prepares a tree of ExprState nodes that mirrors the first tree. The ExprStates contain run-time state needed to execute the Expr tree.


Yes I am seeing that in the code.  
5. The most common nodes in the expression trees are the ExecEvalVar,
ExecEvalConst and ExecEvalParam.

Well, that's obviously going to depend on the query.

Indeed yes, it does, but still for most cases the ExecEvalVar or ExecEvalScalarVar is seen a lot of times (I am trying only simple queries which take most data from disk) which is why i said that. Anyways you are right there.
 

I might be wrong somewhere (especially most people would be able to say
a lot about the 5th point). But if the above were to be correct then how
and why are the ExecMakeFunctionResultNoSets, ExecEvalRelabelType,
ExecEvalFuncArgs and the likes are used?

ExecMakeFunctionResultNoSets is used to evaluate function calls. The first function call invocation always uses ExecMakeFunctionResult, but if ExecMakeFunctionResult sees on that first invocation that it was not a set-returning-function, it changes the evaluator function for subsequent invocations to ExecMakeFunctionResultNoSets. ExecMakeFunctionResultNoSets does the same thing as ExecMakeFunctionResult, but skips the checks for set-returning functions, making the evaluation a bit faster.

ExecEvalFuncArgs is used by ExecMakeFunctionResult to evaluate the function arguments.

ExecEvalRelabelType is used to evaluate RelabelType nodes. RelabelType doesn't really do anything, it's just a placeholder when a type is cast to another, and the source and target types are binary compatible.

did not know the last fact.  

I wanted to see how the expression tree gets into form before it gets
into the ExecQual for parse by ExecEvalExpr function. Is there a way to
see the Expression Tree so that I get a better idea about what is
happening?

set debug_print_plan=on

I am already using the postgresql server with -d 4 option and it shows a lot of things. But I am not able to see the Expression State trees. OK. I know that the output DOES show the 'expr' entries. But if those are what make the Expression _tree_ then I am not able to understand them. A little help on that would be generous. 
 
--
 Heikki Linnakangas
 EnterpriseDB   http://www.enterprisedb.com

Regards,
Vaibhav 

Re: How to look at the Expression Trees

От
Heikki Linnakangas
Дата:
On 21.03.2011 14:37, Vaibhav Kaushal wrote:
> I am already using the postgresql server with -d 4 option and it shows a
> lot of things. But I am not able to see the Expression State trees.

To be precise, debug_print_plan=on prints the expression tree that comes 
from planner, not the execution tree of ExprStates. But the structure of 
the ExprState tree is the same as the planner tree, you just have 
ExprState nodes in place of Expr nodes.

> OK. I
> know that the output DOES show the 'expr' entries. But if those are what
> make the Expression _tree_ then I am not able to understand them. A little
> help on that would be generous.

It is indeed a tree that gets printed with debug_print_plan. There's 
more than the expression tree there, with information about planner the 
relations involved etc. Look for "targetlist" and "qual" fields in the 
output, that's where the expression trees are.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


Re: How to look at the Expression Trees

От
Vaibhav Kaushal
Дата:
Hi,

You said:

ExecMakeFunctionResultNoSets is used to evaluate function calls.

What are the 'functions' there? Are they the user supplied pl/PGSQL style user functions, the functions handled by fmgr or are they just another C function which make the Expression Evaluator?

Regards,
Vaibhav 

Re: How to look at the Expression Trees

От
Heikki Linnakangas
Дата:
On 22.03.2011 05:39, Vaibhav Kaushal wrote:
> You said:
>
> ExecMakeFunctionResultNoSets is used to evaluate function calls.
>
> What are the 'functions' there? Are they the user supplied pl/PGSQL style
> user functions, the functions handled by fmgr or are they just another C
> function which make the Expression Evaluator?

Functions you can use in queries, written in PL/pgSQL or other PL 
languages. Including user-defined and built-in functions, and functions 
implementing operators.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com