Skip site navigation (1) Skip section navigation (2)

Re: Query caching

From: Daniel Freedman <freedman(at)ccmr(dot)cornell(dot)edu>
To: KuroiNeko <evpopkov(at)carrier(dot)kiev(dot)ua>
Cc: pgsql-general(at)postgresql(dot)org, freedman(at)ccmr(dot)cornell(dot)edu
Subject: Re: Query caching
Date: 2000-11-01 04:18:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On the topic of query cache (or maybe this is just tangential and I'm

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

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,


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

In response to


pgsql-hackers by date

Next:From: KuroiNekoDate: 2000-11-01 04:41:05
Subject: Re: Query caching
Previous:From: Tatsuo IshiiDate: 2000-11-01 03:45:44
Subject: WAL: postmaster won't start

pgsql-general by date

Next:From: KuroiNekoDate: 2000-11-01 04:41:05
Subject: Re: Query caching
Previous:From: Jim MercerDate: 2000-11-01 02:19:31
Subject: Re: date question?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group