Re: Query caching - Mailing list pgsql-general

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....
>