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