Re: [PATCH] Caching for stable expressions with constant arguments v3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Caching for stable expressions with constant arguments v3
Date
Msg-id 9104.1323724084@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Caching for stable expressions with constant arguments v3  (Marti Raudsepp <marti@juffo.org>)
List pgsql-hackers
Marti Raudsepp <marti@juffo.org> writes:
> The 'struct Expr' type could have another attribute that stores
> whether its sub-expressions contain stable/volatile functions, and
> whether it only contains of constant arguments. This attribute would
> be filled in for every Expr by eval_const_expressions.

Hmm.  I'm a bit hesitant to burn the extra space that would be required
for that.  On the other hand it is a relatively clean solution to
postponing the whether-to-actually-cache decisions until runtime.
But on the third hand, I don't know whether this is really much cleaner
than always injecting CacheExpr and having some runtime flag that
prevents it from caching.  The argument that CacheExpr could confuse
equal() checks applies just as much to this, unless you make some ad-hoc
decision that equal() should ignore these flag bits.

> This would decouple expression caching from the planner entirely;
> CacheExpr wouldn't exist anymore. AFAICT this would also let us get
> rid of contain_mutable_functions_walker() and possibly others.

Yeah, you could imagine getting rid of tree walks for both mutability
and returns-set tests, and maybe other things too --- once you've paid
the price of an expression attributes flag word, there's room for quite
a few bits in there.  Don't know offhand if that's attractive enough to
tip the scales.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ross Reedstrom
Date:
Subject: Re: includeifexists in configuration file
Next
From: Simon Riggs
Date:
Subject: Re: JSON for PG 9.2