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: | Raw Message | Whole Thread | 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 |