From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: [PATCH] Caching for stable expressions with constant arguments v3 |
Date: | 2011-12-05 17:31:10 |
Message-ID: | 136.1323106270@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marti Raudsepp <marti(at)juffo(dot)org> writes:
> On Sun, Dec 4, 2011 at 22:53, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> This comment in RelationGetExpressions() also worries me:
> [...]
>> Do the injected CacheExprs screw up that equality? Or the constraint
>> exclusion logic in predtest.c?
> I suspect these cases are guaranteed not to produce any CacheExprs.
> They're always immutable expressions. If they contain Var references
> they're stored as is (not cachable); if not, they're folded to a
> constant.
> But I will have to double-check all the callers; it might be a good
> idea to disable caching anyway in these cases.
I think if you have some call sites inject CacheExprs and others not,
it will get more difficult to match up expressions that should be
considered equal. On the whole this seems like a bad idea. What is
the reason for having such a control boolean in the first place?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-12-05 17:53:23 | Re: Inlining comparators as a performance optimisation |
Previous Message | Peter Eisentraut | 2011-12-05 17:27:41 | exit() calls in libraries |