mlw <markw@mohawksoft.com> writes:
> It seems there should be 3 core function cache levels:
There should be 3, but not defined like this:
> 1) "noncacheable," this should always be called every time it is used.
> 2) "cachable," this should mean that it will be called only once per unique set
> of parameters within a transaction.
> 3) "persistent," this could mean it never needs to be called twice.
We will *not* implement function caching as implied by #2. What we want
is a definition that says that it's okay to omit redundant calls, not
one that promises we will not make any redundant calls.
Reasonable definitions would be:
1. noncachable: must be called every time; not guaranteed to return same
result for same parameters even within a query. random(), timeofday(),
nextval() are examples.
2. fully cachable: function guarantees same result for same parameters
no matter when invoked. This setting allows a call with constant
parameters to be constant-folded on sight.
3. query cachable: function guarantees same result for same parameters
within a single query, or more precisely within a single
CommandCounterIncrement interval. This corresponds to the actual
behavior of functions that execute SELECTs, and it's sufficiently strong
to allow the function result to be used in an indexscan, which is what
we really care about.
I'm by no means wedded to those names ... maybe someone can think of
better terminology.
> With the above definitions, it would make sense to have "iscacheable" as the
> default for a function.
I'd still vote for noncachable as the default; unsurprising behavior is
to be preferred over maximum performance IMHO.
regards, tom lane
