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 по дате отправления: