From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
---|---|
To: | "Bexley Hall" <bexley401(at)yahoo(dot)com>,pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query caching absent "query caching" |
Date: | 2012-11-25 15:10:17 |
Message-ID: | 20121125151018.50800@gmx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Froehlich | 2012-11-25 17:19:04 | large INSERT leads to "invalid memory alloc" |
Previous Message | Guillaume Lelarge | 2012-11-25 09:44:16 | Re: Revoke "drop database" even for superusers? |