From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Bexley Hall <bexley401(at)yahoo(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query caching absent "query caching" |
Date: | 2012-11-25 20:12:07 |
Message-ID: | CAFj8pRB1usnxf6NXL=zKbOd9Poy3S+_HWjBV2R_WsDxiVKD06Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2012/11/25 Bexley Hall <bexley401(at)yahoo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Vlad | 2012-11-25 23:07:44 | Re: High SYS CPU - need advise |
Previous Message | Tom Lane | 2012-11-25 20:10:52 | Re: large INSERT leads to "invalid memory alloc" |