Re: How to look at the Expression Trees

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