Re: Query caching

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

In response to

Responses

Browse pgsql-general by date

  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)?

Browse pgsql-hackers by date

  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