Re: Query caching
Poul L. Christiansen <poulc@cs.auc.dk>
From: "Poul L. Christiansen" <poulc@cs.auc.dk>
To: Daniel Freedman <freedman@ccmr.cornell.edu>
Cc: KuroiNeko <evpopkov@carrier.kiev.ua>, pgsql-general@postgresql.org
Date: 2000-11-01T10:16:58Z
Lists: pgsql-hackers
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 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)? 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 have this possibility. But Cold Fusion costs 1300$ :( Poul L. Christiansen