Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
>
>>At execution time the executor can cache the results of expressions
>>flagged as constant at execution, assuming there's somewhere safe to
>>cache the result for just that execution (ExprState?).
>
>
> That would be the problem; there isn't anyplace appropriate. I'm not
> sure this is really worth pursuing...
Bear with me for a moment then :) .. It'd be nice to have for cases
where there's a frequently evaluated expensive expression that could be
constant-folded if it wasn't parameterized.
I guess that ExprState does not live long enough to be useful. How about
a single-entry cache in the expression node itself, with cache validity
tied to the ExprContext it was evaluated in? i.e. something like: use a
global counter to assign a sufficiently-unique ID to each ExprContext,
copy the context's ID to the cache when filling the cache, and only
treat the cache as valid when the cache's ID matches the current
context's ID.
>>I took a quick look through the executor code, but couldn't see where
>>STABLE function results are cached (for the same arguments).
>
>
> They aren't. STABLE is not a cache-enabling modifier: what it is
> actually for is to license the function to be used in an indexscan
> qualification.
> This is why the definition of STABLE refers to holding still throughout
> a table scan, rather than other reasonable alternatives one might
> consider (such as being constant throughout one transaction).
Ok. The CREATE FUNCTION documentation is a bit misleading: it does
specify the requirement to be immutable during a single table scan, but
the text and examples that follow describe a stronger requirement.
How about introducing a function modifier that provides stronger
guarantees than STABLE, along the lines of "immutable during execution
of a single SQL statement"? From a quick skim of pg_proc, it looks like
most if not all of the existing STABLE functions also meet the stronger
requirement.
-O