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
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
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
2012/11/25 Bexley Hall bexley...@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
Hi,
In the absence of query caching AND NOT WANTING TO FORCE
THE APPLICATION TO DO SO EXPLICITLY, I'm looking for ideas
as to how I should future-safe the design of some custom
user base types and functions thereon.
Specifically, I have several computationally expensive
functions that derive
Hello
you can try use plperl as cache
http://okbob.blogspot.cz/2007/12/using-shared-as-table-cache-in-plperl.html
Regards
Pavel Stehule
2012/11/25 Bexley Hall bexley...@yahoo.com:
Hi,
In the absence of query caching AND NOT WANTING TO FORCE
THE APPLICATION TO DO SO EXPLICITLY, I'm looking
Daniel Freedman wrote:
On the topic of query cache (or maybe this is just tangential and I'm
confused):
I've always heard that Oracle has the ability to essentially suck in as
much of the database into RAM as you have memory to allow it, and can then
just run its queries on that in-RAM
PostgreSQL hits the disk on UPDATE/DELETE/INSERT operations. SELECT's
are cached, but the default cache is only ½MB of RAM. You can change
this to whatever you want.
I'm using Cold Fusion and it can cache queries itself, so no database
action is necessary. But I don't think PHP and others
On Wed, Nov 01, 2000 at 10:16:58AM +, Poul L. Christiansen wrote:
PostgreSQL hits the disk on UPDATE/DELETE/INSERT operations. SELECT's
are cached, but the default cache is only ½MB of RAM. You can change
this to whatever you want.
That sound like a very cool thing to do, and the default
Frank Joerdens wrote:
On Wed, Nov 01, 2000 at 10:16:58AM +, Poul L. Christiansen wrote:
PostgreSQL hits the disk on UPDATE/DELETE/INSERT operations. SELECT's
are cached, but the default cache is only ½MB of RAM. You can change
this to whatever you want.
That sound like a very cool
(Incidentally, we've toyed around with developping a
query-caching
system that would sit betwen PostgreSQL and our DB libraries.
Sounds amazing, but requires some research, I guess. However, in
many
cases one would be more than happy with cahced connections. Of
course,
11 matches
Mail list logo
