>>>>> "DJD" == Daniel John Debrunner <[EMAIL PROTECTED]> writes:
DJD> I think modifications to the cache would be useful for b), so
DJD> that entries in the cache (through generic apis, not specific
DJD> to store) could mark how "useful/valuable" they are. Just a
DJD> simple scheme, lower numbers less valuable, higher numbers
DJD> more valuable, and if it makes it easier to fix a range,
DJD> e.g. 0-100, then that would be ok. Then the store could added
DJD> pages to the cache with this weighting, e.g. (to get the
DJD> general idea)
DJD> pages for backup - weight 0
DJD> overflow column pages - weight 10
DJD> regular pages - weight 20
DJD> leaf index pages - weight 30
DJD> root index pages 80
DJD> This weight would then be factored into the decision to throw pages out
DJD> or not.
I agree that we need some mechanism to prevent operations from filling
the cache with pages that is not likely to be accesssed again in the
near future. However, I am afraid that a very detailed "cost-based"
scheme may create a significant overhead compared to a simple LRU
scheme.
One may operate with separate LRU queues for different weights, but I
guess the number of possible weights will have to be restricted in
that case.
I am also not convinced that it is the type of page that is the most
important criteria for caching. What matters is access frequency.
The page type may give a hint, but leaf pages of one index may be more
frequently accessed than root pages of other indexes.
The type of access is also a relevant criteria. Pages accessed
sequentially is often less likely to be accessed again in the near
future than pages accessed by direct lookup. A separate LRU queue for
sequentially accessed pages may prevent backup and other sequentially
scans (e.g., select * from t) from throwing out directly accessed
pages (e.g., index pages and data pages accessed through indexes.)
DJD> This project could be independent of the online backup and could have
DJD> benfits elsewhere.
I agree.
--
Øystein
