From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | 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 05:18:56 |
Message-ID: | 18766.1096262336@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Neil Conway <neilc(at)samurai(dot)com> writes:
> I think the conclusion of past discussions about this feature is that
> it's a bad idea. Last I checked, MySQL has to clear the *entire* query
> cache when a single DML statement modifying the table in question is
> issued.
Do they actually make a rigorous guarantee that the cached result is
still accurate when/if it is returned to the client? (That's an honest
question --- I don't know how MySQL implements this.)
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amol Bhutada | 2004-09-27 05:26:21 | unsubscribe |
Previous Message | Neil Conway | 2004-09-27 05:03:01 | Re: Caching of Queries |