EXEC_EVALDEBUG debugging broken?

From: peter(dot)trautmeier(at)gmx(dot)de
To: pgsql-hackers(at)postgresql(dot)org
Subject: EXEC_EVALDEBUG debugging broken?
Date: 2007-07-24 09:36:06
Message-ID: 20070724093606.6420@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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=1018 cost=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 it is encountered
in ExecQual()?

Regards,
Peter

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2007-07-24 09:45:12 Re: avoiding WAL logging in 8.3
Previous Message Gregory Stark 2007-07-24 08:02:32 Re: autovacuum default parameters