Re: Table scan and LRU caching

> By doing so, I guess, the blocks of often used tables gets a better
> chance to "stay around" in memory, minimizing large disk reads?
> You'll need plenty of RAM though :-)

Exactly! That's the idea. Reading from memory is much, much faster than reading from disk. So the more memory you have, the bigger you can make the buffer cache, and the faster your database will perform (theoretically).

Blocks of often used tables tend to stay in memory. They are less likely to get "aged" out.  

> When do blocks get placed not at the MRU end (when first
> fetched)? Do blocks age off towards the LRU end unevenly?

When an index is used to read specific blocks, the blocks get placed on the most recently used end. The next time the block is accessed, it is moved to the MRU end of the list. If the block is never accessed again, it will age off towards the LRU end of the list. If your buffer cache is not big enough, blocks will move to the LRU end of the list rather quickly.  

HTH,
Brian

-- 
========================================
Brian Peasland
Raytheons Systems at
  USGS EROS Data Center
These opinions are my own and do not
necessarily reflect the opinions of my 
company!
========================================