Oliver Jowett <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
