Von: Tom Lane [EMAIL PROTECTED]
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
[EMAIL PROTECTED] writes:
Is it possible to store the calculated logical value of certain
expressions, e.g. boolean OpExprs, in their ExprState on a per tuple
basis to reuse them later? (I guess I described some kind of
'condition cache' here.)
No ... what would be the point? If the
Hi all,
I am using version 8.2.4 of the source and compiled it with
both OPTIMIZER_DEBUG and EXEC_EVALDEBUG enabled to take a look
at how quals are evaluated by the executor.
However, when I issue a query like
SELECT name FROM city WHERE population 10 LIMIT 10;
I get the following debug
[EMAIL PROTECTED] writes:
WARNING: could not dump unrecognized node type: 404
ExecQual: qual is (
{
}
)
Yeah, that code is toast, we probably ought to remove it. It hasn't
worked since the changes to make the executor treat plan trees as
read-only. Making it work would require
Von: Tom Lane [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
WARNING: could not dump unrecognized node type: 404
ExecQual: qual is (
{
}
)
Yeah, that code is toast, we probably ought to remove it. It hasn't
worked since the changes to make the executor treat plan trees as
[EMAIL PROTECTED] writes:
Interesting, what do you mean by Plan trees are 'read only' now? Is it the
distinction between Plan trees and their corresponding PlanState nodes that
indicate the 'read only' behaviour and the 'writeable' state of the Plan,
respectively, that was introduced at
