Thread: EXEC_EVALDEBUG debugging broken?
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 < 100000 LIMIT 10;
I get the following debug output from postgres:
After canonicalize_qual() {OPEXPR :opno 97 :opfuncid 66 :opresulttype 16 :opretset false :args ( {VAR
:varno 1 :varattno 4 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 4
} {CONST :consttype 23 :constlen 4 :constbyval true :constisnull false :constvalue 4 [
-96-122 1 0 ] } ) }
RELOPTINFO (1): rows=1018 width=88 baserestrictinfo: city.population < 100000 path list: SeqScan(1)
rows=1018cost=0.00..66.16
cheapest startup path: SeqScan(1) rows=1018 cost=0.00..66.16
cheapest total path: SeqScan(1) rows=1018 cost=0.00..66.16
WARNING: could not dump unrecognized node type: 404
ExecQual: qual is ( { }
)
WARNING: could not dump unrecognized node type: 404
ExecQual: qual is ( { }
)
... and many more of this WARNINGs.
What happens to the OpExpr on its way from canonicalize_qual() to ExecQual() that makes _outNode() stumble over it when
itis encounteredin ExecQual()?
Regards,
Peter
peter.trautmeier@gmx.de 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 teaching outfuncs.c how to dump
all the different expression state node types, which seems like more
maintenance effort than is justified for debug support that no one uses.
(Dumping an expression tree over again on each evaluation seems of
pretty questionable usefulness to me anyway.)
I'd suggest using EXPLAIN VERBOSE instead, which will give you
the same printout that this would have given you back when it did
work, but only once instead of over again for each row.
regards, tom lane
Von: Tom Lane <tgl@sss.pgh.pa.us>
> peter.trautmeier@gmx.de 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.
Thanks Tom!
Interesting, what do you mean by Plan trees are 'read only' now? Is it the distinction between Plan trees and their
correspondingPlanState nodes that indicate the 'read only' behaviour and the 'writeable' state of the Plan,
respectively,that was introduced at that time?
> Making it work would require teaching outfuncs.c how to dump
> all the different expression state node types, which seems like more
> maintenance effort than is justified for debug support that no one uses.
Ok, but what type has this qual from my example that was once a OpExpr as soon as it arrives at ExecQual? It's
obviouslynot a OpExpr - otherwise _outNode wouldn't stumble over it.
(Is there a way do get this type info with gdb's help?)
> I'd suggest using EXPLAIN VERBOSE instead, which will give you
> the same printout that this would have given you back when it did
> work, but only once instead of over again for each row.
Thanks, I hadn't seen the VERBOSE option before.
Regards,
Peter
peter.trautmeier@gmx.de writes:
> Interesting, what do you mean by Plan trees are 'read only' now? Is it the distinction between Plan trees and their
correspondingPlanState nodes that indicate the 'read only' behaviour and the 'writeable' state of the Plan,
respectively,that was introduced at that time?
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.
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 ...
> (Is there a way do get this type info with gdb's help?)
"p *(Node *) ptr" ought to do it.
regards, tom lane
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
peter.trautmeier@gmx.de 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 expression is known constant
it'll be folded to a Const at plan time, and if it's not constant I
don't see how we know when we can cache its value.
regards, tom lane