On 25.09.2011 05:09, Marti Raudsepp wrote:
> This is the third version of my CacheExpr patch.
This seems to have bitrotted, thanks to the recent refactoring in
> For explanation about design decisions, please read these earlier messages:
I wonder if it would be better to add the CacheExpr nodes to the tree as
a separate pass, instead of shoehorning it into eval_const_expressions?
I think would be more readable that way, even though a separate pass
would be more expensive. And there are callers of
eval_const_expressions() that have no use for the caching, like
This comment in RelationGetExpressions() also worries me:
> * Run the expressions through eval_const_expressions. This is not just an
> * optimization, but is necessary, because the planner will be comparing
> * them to similarly-processed qual clauses, and may fail to detect valid
> * matches without this. We don't bother with canonicalize_qual, however.
> result = (List *) eval_const_expressions(NULL, (Node *) result);
Do the injected CacheExprs screw up that equality? Or the constraint
exclusion logic in predtest.c?
In response to
pgsql-hackers by date
|Next:||From: Tomas Vondra||Date: 2011-12-04 21:04:40|
|Subject: Re: cannot read pg_class without having selected a database
/ is this a bug?|
|Previous:||From: Tom Lane||Date: 2011-12-04 20:29:06|
|Subject: Re: planner fails on HEAD |