Re: Query caching absent "query caching"

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

Responses

Browse pgsql-general by date

  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?