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
