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. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
