I think the notion that data is managed outside of the database is bogus. Query
caching can improve performance in some specific, but popular, scenarios.
Saying it does not belong within the database and is the job of the
application, is like saying file caching is not a job of the file system but is
the job of the application.
This is a functionality many users want, and can be justified by some very
specific, but very common, scenarios. It is not me to say if it is worth the
work, or if it should be done. From the perspective of the user, having this
capability within the database is an important feature, I want to make the
argument.
Greg Copeland wrote:
>
> I previously replied to you vaguely describing a way you could implement
> this by using a combination of client side caching and database tables
> and triggers to allow you to determine if your cache is still valid.
> Someone came right behind me, Tom maybe??, and indicated that the
> proper/ideal way to do this would be to using postgres' asynchronous
> database notification mechanisms (listen/notify I believe were the
> semantics) to alert your application that your cache has become
> invalid. Basically, a couple of triggers and the use of the list/notify
> model, and you should be all set.
>
> Done properly, a client side cache which is asynchronously notified by
> the database when it's contents become invalid should be faster than
> relying on MySQL's database caching scheme. Basically, a strong client
> side cache is going to prevent your database from even having to return
> a cached result set while a database side cache is going to always
> return a result set. Of course, one of the extra cool things you can do
> is to cache a gzip'd copy of the data contents which would further act
> as an optimization preventing the client or web server (in case they are
> different) from having to recompress every result set.
>
> In the long run, again, if properly done, you should be able to beat
> MySQL's implementation without too extra much effort. Why? Because a
> client side cache can be much smarter in the way that it uses it's
> cached contents much in the same way an application is able to better
> cache it's data then what the file system is able to do. This is why an
> client side cache should be preferred over that of a database result set
> cache.
>
> Greg
>
