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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-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


pgsql-hackers by date

Next:From: Marc G. FournierDate: 2000-11-01 12:42:57
Subject: Re: Re: [GENERAL] Query caching
Previous:From: Karel ZakDate: 2000-11-01 10:13:03
Subject: Re: Re: [GENERAL] Query caching

pgsql-general by date

Next:From: Alberto Otero GarcíaDate: 2000-11-01 11:34:59
Subject: mysqldump export and pg_dump import
Previous:From: Marc SCHAEFERDate: 2000-11-01 10:16:24
Subject: Re: True ACID under linux (no fsync)?

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