Re: Query caching absent "query caching"

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Query caching absent "query caching"
Дата
Msg-id CAFj8pRB1usnxf6NXL=zKbOd9Poy3S+_HWjBV2R_WsDxiVKD06Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query caching absent "query caching"  (Bexley Hall <bexley401@yahoo.com>)
Список pgsql-general
2012/11/25 Bexley Hall <bexley401@yahoo.com>:
> Hi Pavel,
>
> On 11/24/2012 9:47 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> you can try use plperl as cache
>>
>>
>> http://okbob.blogspot.cz/2007/12/using-shared-as-table-cache-in-plperl.html
>
>
> But how is this any different than just creating a named/shared
> table manually?

access to memory is faster than access to table - but it is limited.

>
> And, how do further/additional accesses (by other clients or
> the same client) *augment* the shared table?
>
> In terms of my "application":
> - Assume client A does a query that evaluates expensive_function()
>   for rows 1, 5 and 93
> - Client B does a query that evaluates expensive_function() for
>   rows 3, 5 and 97
> - Client C does a query that evaluates expensive_function() for
>   rows 93, 95 and 97
> (no one alters any of the data on which expensive_function() relies
> in this time interval)
>
> Then, A should bear the cost of computing the results for 1, 5 and 93.
> B should bear the cost of computing 3 and 97 -- but should be able to
> benefit from A's computation of 5.  C should bear the cost of computing
> 95 but benefit from the previous computations of 93 and 97.
>

depends on implementation - probably you cannot to design a generic
solution, but for some not wide defined tasks, you can find effective
solutions.

Regards

Pavel

> Thx,
> --don


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: large INSERT leads to "invalid memory alloc"
Следующее
От: Vlad
Дата:
Сообщение: Re: High SYS CPU - need advise