Re: EXEC_EVALDEBUG debugging broken? - Mailing list pgsql-hackers

From peter.trautmeier@gmx.de
Subject Re: EXEC_EVALDEBUG debugging broken?
Date
Msg-id 20070725122038.323700@gmx.net
Whole thread Raw
In response to Re: EXEC_EVALDEBUG debugging broken?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: EXEC_EVALDEBUG debugging broken?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Von: Tom Lane <tgl@sss.pgh.pa.us>
> Yeah, exactly.  ExecInitExpr builds an ExprState tree that mirrors the
> structure of the Expr tree but contains all the run-time-variable data.
> This tree is what's now being passed to ExecQual.

I see, and ExecInitExpr wraps the OpExpr in an FuncExprState.

Is it possible to store the calculated logical value of certain expressions, e.g. boolean OpExprs, in their ExprState
ona per tuple basis to reuse them later?
 
(I guess I described some kind of 'condition cache' here.)

> The problem is that outfuncs.c knows about all the Expr node types and
> none of the ExprState types, there being no need to dump the latter in
> normal use.  There is a valid argument that we ought to support dumping
> PlanState and ExprState trees for debugging purposes, but it just seems
> like more maintenance effort than it's worth ...

I don't know how often these ExprState nodes really change and how much maintenance they require, but I get your
point.

> > (Is there a way do get this type info with gdb's help?)
> 
> "p *(Node *) ptr" ought to do it.

Thanks, that works.

Regards,
Peter


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Kerberos warnings on win32
Next
From: peter.trautmeier@gmx.de
Date:
Subject: Re: Design: Escort info from WHERE clause to executor?