Re: Query caching

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 database (or db subset) without doing
disk I/O (which I would probably imagine is one of the more expensive
parts of a given SQL command). I've looked for references as to
Postgresql's ability to do something like this, but I've never been
certain if it's possible. Can postgresql do this, please? And, if not,
does it have to hit the disk for every SQL instruction (I would assume
so)?

I would imagine that the actual query cache would be slightly orthogonal
to this in-RAM database cache, in as much as it would actually store the
results of specific queries, rather than the complete tuple set on which
to run queries. However, I would imagine that both schemes would provide
performance increases.

Also, as KuroiNeko writes below about placing the query cache outside the
actual DBMS, don't some webservers (or at least specific custom coding
implementations of them) just cache common query results themselves?
(Not that it would necessarily be bad for the DBMS to do so, I
wouldn't know enough about this to surmise.)

I'd appreciate any pointers to more information on specific performance
tuning in this area (IMHO, it would probably be a boon to the postgresql
database and its community, if there existed some reference like
O'Reilly's _Oracle Performance Tuning_ that was focused on Postgresql.)

Thanks for any extra info,

Daniel

On Tue, 31 Oct 2000, KuroiNeko wrote:

> > Here's a simple design that I was tossing back and forth. Please
> > understand that I'm not saying this is the best way to do it, or even a
> > good way to do it. Just a possible way to do it.
>
> Sounds interesting, I certainly have reasons to play bad guy, but that's
> what I always do, so nevermind :)
> However, there's one major point where I disagree. Not that I have real
> reasons to, or observation or analysis to background my position, just a
> feeling. And the feeling is that connection/query cache should be separate
> from DBMS server itself.
> Several things come to the mind right off, like possibilities to cache
> connections to different sources, like PGSQL and Oracle, as well as a
> chance to run this cache on a separate box that will perform various
> additional functions, like load balancing. But that's right on the surface.
> Still in doubt....
>