Hi,
In the absence of query caching AND NOT WANTING TO FORCE
THE APPLICATION TO DO SO EXPLICITLY, I'm looking for ideas
as to how I should "future-safe" the design of some custom
user base types and functions thereon.
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?
[I am working in a fixed, constrained resource environment so
the idea of explicitly building a temporary table to hold these
results in the absence of a smart query caching strategy is not
possible -- the builder(s) of such tables would have to know
too much about each other to not exhaust the resources available!]
Thanks!
--don