Re: EXEC_EVALDEBUG debugging broken?

Поиск
Список
Период
Сортировка
От peter.trautmeier@gmx.de
Тема Re: EXEC_EVALDEBUG debugging broken?
Дата
Msg-id 20070725122038.323700@gmx.net
обсуждение исходный текст
Ответ на Re: EXEC_EVALDEBUG debugging broken?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: EXEC_EVALDEBUG debugging broken?
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Kerberos warnings on win32
Следующее
От: peter.trautmeier@gmx.de
Дата:
Сообщение: Re: Design: Escort info from WHERE clause to executor?