Re: Again, sorry, caching. - Mailing list pgsql-hackers

From mlw
Subject Re: Again, sorry, caching.
Date
Msg-id 3C9610EB.52E8828C@mohawksoft.com
Whole thread Raw
In response to Again, sorry, caching.  (mlw <markw@mohawksoft.com>)
Responses Re: Again, sorry, caching.  (Greg Copeland <greg@CopelandConsulting.Net>)
List pgsql-hackers
Greg Copeland wrote:
> 
> On Mon, 2002-03-18 at 08:15, mlw wrote:
> > "Mattew T. O'Connor" wrote:
> > >
> [snip]
> 
> >
> > >The primary use that you have suggested is for web sites,
> > > and they certainly won't mind of the cache is 0.3seconds out of date.
> >
> > Again, if they don't care about accuracy, then they will use MySQL. PostgreSQL
> > is a far better system. Making PostgreSQL less accurate, less "correct" takes
> > away, IMHO, the very reasons to use it.
> >
> 
> If you are using a web site and you need real time data within 0.3s,
> you've implemented on the wrong platform.  It's as simple as that.  In
> the web world, there are few applications where a "0.3s" of a window is
> notable.  After all, that "0.3s" of a window can be anywhere within the
> system, including the web server, network, any front end caches, dns
> resolutions, etc.

This is totally wrong! An out of date cache can cause errors by returning
results that are no longer valid, thus causing lookup issues. That is what ACID
compliance is all about.

> 
> I tend to agree with Mettew.  Granted, there are some application
> domains where this can be critical...generally speaking, web serving
> isn't one of them.
> 
> That's why all of the solutions I offered were pointedly addressing a
> web server scenario and not a generalized database cache.  I completely
> agree with you on that.  In a generalized situation, the database should
> be managing and caching the data (which it already does).

But it does not cache a query. An expensive query which does an index range
scan and filters by a where clause could invalidate a good number of buffers in
the buffer cache. If this or a number of queries like it are frequently
repeated, verbatim, in a seldom changed table, why not cache them within
PostgreSQL? It would improve overall performance by preserving more blocks in
the buffer cache and eliminate a number of queries being executed.

I don't see how caching can be an argument of applicability. I can understand
it from a time/work point of view, but to debate that it is a useful feature
seems ludicrous.


pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: Again, sorry, caching.
Next
From: "Luis Alberto Amigo Navarro"
Date:
Subject: Re: postgres is not using tas