Buffer Manager

Definition

The Buffer Manager manages an in-memory cache — the buffer pool — of disk pages, so that frequently accessed data can be served from RAM instead of much slower disk I/O, and so writes can be batched efficiently rather than hitting disk on every single change.

How It Works — Example

When the Query Processor needs a page of data, it asks the Buffer Manager for it. If the page is already present in the buffer pool (a cache hit), it is returned immediately with no disk access. If it is not present (a cache miss), the Buffer Manager asks the Storage Manager to load that page from disk into a free — or evicted — buffer frame. Pages that have been modified ("dirty" pages, as marked by the Storage Manager) are eventually flushed back to disk, either on a periodic schedule or when their frame needs to be reused for something else. When the pool is full and a new page must be loaded, a replacement policy — such as LRU (Least Recently Used) or a clock algorithm — decides which currently cached page gets evicted.

Example: a small, frequently queried departments table tends to stay resident in the buffer pool almost permanently, since it is read constantly and easily fits in memory — giving very fast repeated lookups. A huge, rarely touched archived_exam_logs table, by contrast, causes far more cache misses and real disk reads whenever it is scanned, since it doesn't fit entirely in the pool and isn't accessed often enough to justify staying resident.

Edge Cases and Pitfalls

• An undersized buffer pool causes thrashing. If the buffer pool is too small for the actual "working set" of frequently used pages, pages get evicted and then immediately re-read from disk over and over — a phenomenon called thrashing that hurts performance far more than a moderate increase in allocated memory would cost to fix.
• One large scan can evict everyone else's cached pages. A single large, unindexed sequential scan (for example, an unfiltered report query over a huge table) can flush the buffer pool's useful, frequently-used pages out to make room for the scan's own pages — degrading performance for every other concurrent user's queries. Some engines mitigate this with special, separate scan buffers.
• Buffer Manager durability depends on the Transaction Manager's logging. Because dirty pages are not written to disk immediately, if the system crashes before a dirty page is flushed, correct recovery depends entirely on the Transaction Manager's write-ahead log having already recorded the change durably — the Buffer Manager's caching and the Transaction Manager's durability guarantees are tightly linked, not independent concerns.

Key Takeaways / Interview Q&A

Q: What is the core purpose of the Buffer Manager? A: To cache disk pages in memory (the buffer pool) so frequently accessed data can be served from RAM instead of slow disk I/O, and to batch writes efficiently.

Q: What is "thrashing," and why does it happen? A: Thrashing is when pages are repeatedly evicted from an undersized buffer pool and then immediately re-read from disk, because the pool cannot hold the actual working set of frequently used pages.

Q: Why can a single large report query hurt the performance of everyone else's queries at the same time? A: Because a large sequential scan can flush the buffer pool's normally-cached, frequently-used pages out to make room for its own pages, forcing other users' subsequent queries to re-read from disk.