Bexley Hall wrote:
> Specifically, I have several computationally expensive
> functions that derive their results from specific values of
> these base types. *Solely*. (For example, area() when
> applied to a given "circle" always yields the same result...
> though this is a trivial/inexpensive function, by comparison).
>
> I can define the base types to set aside space to store
> these results and cache them *in* the base type. Then, serve
> up these cached results when they are needed, again. With
> plan caching, this should (?) reduce the cost of repeated
> queries significantly without the need/benefit for caching the
> actual query results. (Is that true?)
>
> To guard against future enhancements to the server (e.g., if
> query caching is ever implemented, etc.), I assume that all
> such functions should declare themselves as IMMUTABLE? Or,
> does my update of the internal representation of the data
> values (i.e., to include the cached results of each of these
> functions) conflict with this declaration?
As long as a call to a given function with a specific set of
arguments always returns the same result, and there are no *user
visible* side effects of the internal caching, I don't see a
problem with declaring the functions immutable.
Out of curiosity, are you planning on using a process-local cache
(which would start empty for each new connection) or are you
planning to allocate shared memory somehow and coordinate access to
that?
-Kevin