Around 09:51 on Apr 6, 2003, pilsl@goldfisch.at said:
# I remember some discussions about a query-caching-feature (that came up
# after mysql claimed to have it) and googled for similar discussions on
# the hackers list. I found some threads there covering this topic and it
# seems that caching should not be done by postgres but by the application
# or a layer between (a daemon)
I agree that the caching should be done in the application layer.
I've created a framework to do this in java that has brought me a lot of
success. It really makes scaling up easier and is often pretty easy to
retrofit into a poor design.
It is not, however, a replacement for a good design. Just as you
don't want to query the same data from the DB repeatedly, you also don't
want to pull the results back and create object instances (or other data
structures) repeatedly. While I've got decent performance boosts from
caching queries, I've got pretty large ones from avoiding JDBC all
together.
# Somebody already did such a layer or knows of it ? Implementing the
# caching in the caching would be not to easy (for people that never
# programmed caching) with all the shared memory-stuff and
# listen/notify-models.
Most of this isn't an issue in java, or other long-living
multi-threaded process models (smalltalk's comanche or python's zope, for
example). It's easy to make very efficient and safe caches when you have
proper synchronization and and fast communication between threads (i.e.
zero-copy).
--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
