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 eval_const_expressions().

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 process_implied_equality().

This comment in RelationGetExpressions() also worries me:

         * Run the expressions through eval_const_expressions. This is not just 
         * optimization, but is necessary, because the planner will be comparing
         * them to similarly-processed qual clauses, and may fail to detect 
         * matches without this.  We don't bother with canonicalize_qual, 
        result = (List *) eval_const_expressions(NULL, (Node *) result);

Do the injected CacheExprs screw up that equality? Or the constraint exclusion logic in predtest.c?

  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to