On Tue, 19 Mar 2002 12:12:52 CST, "Ross J. Reedstrom" wrote: > On Mon, Mar 18, 2002 at 09:35:51PM -0500, Neil Conway wrote: > > > > > > "It is an application issue" > > > This is completely wrong. Caching can not be done against a database without > > > knowledge of the database, i.e. when the data changes. > > ... > > > > If we're looking to provide a "quick and easy" caching scheme for users > > attracted to MySQL's query cache, why not provide this functionality > > through another application? > > ... > > > > What does everyone think? > > Neil, this sounds like exactly the approach to follow up on: > ... > > Seems like a win all around. Anyone else have comments? > ...
I'm not certain the full direction of the thinking here, however, it seems to me that there are a few considerations that I would like to see/keep in mind: I feel that the caching should be SQL transparent. If it is implemented reasonably well, the performance gain should be pretty much universal. Yes, a large number of queries would never be called again, however, the results still need to be fetched into memory and "caching" them for later reuse should involve little more than a skipped free (think filesystem cache). It makes more sense to specify "non-cachable" in a query for tuning than "cacheable". This also means that just switching databases to PostgreSQL improves my performance. Also, it is very important that the caching should be transparent to the application. This means that the application should be able to connect to the database using the "standard" application interface (i.e., ODBC, PHP, Perl/DBI, etc.) This allows me to port my existing Oracle/DB2/MySQL/etc. application to pgsql through normal porting. If I have to implement a non-standard interface, I can likely gain even more performance through custom code and maintain reasonable database independence. While I am a strong believer in PostgreSQL, many of my customers have other demands/requirements. I still want to be able to use my existing code and libraries when using their database. Sticking with the "standards" allows me to develop best of class applications and interface to best of class databases. It also allows others to easily realize the value of PostgreSQL. Thanks, F Harvell ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])