Re: Caching of Queries

From: Mitch Pirtle <mitch(dot)pirtle(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Aaron Werman <awerman(at)hotmail(dot)com>, Scott Kirkwood <scottakirkwood(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Caching of Queries
Date: 2004-09-27 13:29:58
Message-ID: 330532b6040927062938c1d596@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, 27 Sep 2004 01:18:56 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> IIRC, in our past threads on this topic, it was suggested that if you
> can tolerate not-necessarily-up-to-date results, you should be doing
> this sort of caching on the client side and not in the DB server at all.
> I wouldn't try that in a true "client" scenario, but when the DB client
> is application-server middleware, it would make some sense to cache in
> the application server.

I'd also like to add that when one of the Mambo community members
started running benchmarks of popular Content Management Systems
(CMS), the ones that implemented page-level caching were significantly
more scalable as a result of the decreased load on the database (and
application server, as a result):

http://forum.mamboserver.com/showthread.php?t=11782

Caching at the database level provides the smallest possible
performance boost (at least regarding caching), as caching the query
on the webserver (via ADOdb's query cache) avoids the database server
altogether; and page-level caching gives you the biggest possible
benefit.

Yes, you have to be careful how you cache your data, but for many
applications it is easy to implement a trigger that clears the cache
when certain data is updated.

-- Mitch

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2004-09-27 14:17:56 Re: Caching of Queries
Previous Message Scott Kirkwood 2004-09-27 13:00:14 Re: Caching of Queries