Re: Query caching absent "query caching"

Поиск
Список
Период
Сортировка
От Bexley Hall
Тема Re: Query caching absent "query caching"
Дата
Msg-id 50B27B4A.2070903@yahoo.com
обсуждение исходный текст
Ответ на Re: Query caching absent "query caching"  ("Kevin Grittner" <kgrittn@mail.com>)
Список pgsql-general
Hi Kevin,

On 11/25/2012 8:10 AM, Kevin Grittner wrote:
> 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.

OK.

> 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?

I was planning on writing back the results of each successful
function evaluation into the data type's internal representation.
Ideally, back into PostgreSQL's "master copy" of the data
(though I would settle for hiding it in an anonymous table
behind a view, etc.)

The point is NEVER to have to RE-evaluate any of these functions
for the data on which they are evaluated once they have been
evaluated (assuming the data themselves do not change).  And,
in doing so, make the results of each evaluation available to
other clients regardless of the query which caused them to
be evaluated.

Thx,
--don


В списке pgsql-general по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: large INSERT leads to "invalid memory alloc"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: large INSERT leads to "invalid memory alloc"