Alexandre Benson Smith wrote:

>
> I always wonder the effect of SO cache caching the disk space of the
> pages that are already on FB Cache. :-)
>

<very complete description of the problems of overlapping database and
operating system page caches omitted>

There's some benefit to the database system for having pages in its own
cache, above and beyond the code of a physical read. You don't have to
go down to the physical layers to get a page from cache, and more
important, in classic, you can keep a read lock on it so you know that
the contents are stable.

The whole cache problem is hard. In classic, most connections will
cache a significant number of the same pages - header, current tip,
pointer pages for commonly used tables, the tops of indexes of commonly
used tables - that's why SuperServer was invented. Beyond that, some
applications - gbak being a good example - run very well with very small
caches because they tend to visit a page once and never return. OLAP
tends to need a big cache because it's constantly returning to data.

What I'm saying is that you can run tests and determine what cache size
works for your application in classic or superserver, but your results
won't necessarily apply to other applications.

Regards,


Ann