Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Caching for stable expressions with constant arguments v3

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Caching for stable expressions with constant arguments v3
Date: 2011-12-04 20:53:37
Message-ID: 4EDBDDD1.4050003@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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:
> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00579.php
> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00812.php
> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00833.php

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 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?

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

In response to

Responses

pgsql-hackers by date

Next:From: Tomas VondraDate: 2011-12-04 21:04:40
Subject: Re: cannot read pg_class without having selected a database / is this a bug?
Previous:From: Tom LaneDate: 2011-12-04 20:29:06
Subject: Re: planner fails on HEAD

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group