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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general