| From: | "Poul L(dot) Christiansen" <poulc(at)cs(dot)auc(dot)dk> |
|---|---|
| To: | Daniel Freedman <freedman(at)ccmr(dot)cornell(dot)edu> |
| Cc: | KuroiNeko <evpopkov(at)carrier(dot)kiev(dot)ua>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Query caching |
| Date: | 2000-11-01 10:16:58 |
| Message-ID: | 39FFED9A.E064B36D@cs.auc.dk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alberto Otero García | 2000-11-01 11:34:59 | mysqldump export and pg_dump import |
| Previous Message | Marc SCHAEFER | 2000-11-01 10:16:24 | Re: True ACID under linux (no fsync)? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc G. Fournier | 2000-11-01 12:42:57 | Re: Re: [GENERAL] Query caching |
| Previous Message | Karel Zak | 2000-11-01 10:13:03 | Re: Re: [GENERAL] Query caching |