From: | Bexley Hall <bexley401(at)yahoo(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query caching absent "query caching" |
Date: | 2012-11-25 20:06:38 |
Message-ID: | 50B27A4E.7040007@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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?
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.
Thx,
--don
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-11-25 20:09:27 | Re: large INSERT leads to "invalid memory alloc" |
Previous Message | Stefan Froehlich | 2012-11-25 19:39:45 | Re: large INSERT leads to "invalid memory alloc" |