>>>>> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> As Oystein says I think the main reason to tune checkpoint interval is
MM> some sort of balance between recovery time and performance overhead of
MM> the checkpoint. The last change in this area bumped the log file size
MM> from 100k to 1 meg, and the checkpoint size from 1 log file to 10 log
MM> files. Even this change makes us do many more checkpoints than
MM> competing databases, especially in benchmark situations when other dbs
MM> don't do any checkpoints. Some time based approach may be interesting,
MM> with inputs of how long does a checkpoint take and how long since the
MM> last checkpoint and total log volume rate. There is also the log file
MM> garbage collection issue.
It would be interesting to see a study of how different settings for
the checkpoint interval impact throughput and recovery times. That
seems like well suited for a student project.
MM> I don't think checkpointing is the way to control # dirty pages in the
MM> cache. The current system tries to do this in the clock algorithm, by
MM> having a background thread "clean" dirty pages when it thinks there
MM> are too many. This buffer cache, clock algorithm is pretty simple so
MM> there may be improvements possible there - I believe some have already
MM> been discussed on the list with respect to weighting various
MM> pages.
OK, I was not aware of this mechanism. I guess the benefit of having
two mechanisms that write pages to disk is that the clock algorithm
only writes those pages that are likely to soon be thrown of the
cache. Hence, hot spot pages are normally only written at each
checkpoint.
--
Øystein
