Re: Query caching absent "query caching"

Hello

you can try use plperl as cache

http://okbob.blogspot.cz/2007/12/using-shared-as-table-cache-in-plperl.html

Regards

Pavel Stehule

2012/11/25 Bexley Hall <bexley401(at)yahoo(dot)com>:
> 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
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general