53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
 
|
# 2Q Cache Management Algorithm
|
||
|
|
|
||
|
|
## Metadata
|
||
|
|
|
||
|
|
| Field | Value |
|
||
|
|
|---|---|
|
||
|
|
| Institute | Molodetz Institute — Research & Retrieval Division |
|
||
|
|
| Subject | agent-memory-recency-tracking |
|
||
|
|
| Document type | Source Dossier |
|
||
|
|
| Tier | 1 |
|
||
|
|
| Source title | 2Q Cache Management Algorithm |
|
||
|
|
| Source URL | https://arpit.substack.com/p/2q-cache-management-algorithm |
|
||
|
|
| Source publisher / author | Arpit (Substack newsletter), explaining Johnson & Shasha's 1994 VLDB paper |
|
||
|
|
| Source type | blog post (explainer of a primary paper) |
|
||
|
|
| Source date (published) | Unknown — not stated |
|
||
|
|
| Date researched | 2026-10-09 |
|
||
|
|
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
|
||
|
|
| Research method | web search synthesis |
|
||
|
|
| Confidence | High |
|
||
|
|
| Status | Active |
|
||
|
|
|
||
|
|
## Summary
|
||
|
|
|
||
|
|
An accessible explainer of Johnson & Shasha's 1994 "2Q" buffer-replacement algorithm — a constant-overhead, no-tuning alternative to full LRU that influenced real database buffer-pool design, most notably PostgreSQL's.
|
||
|
|
|
||
|
|
## Key findings
|
||
|
|
|
||
|
|
- 2Q answers whether a constant-overhead-per-access scheme can match LRU/2 page-replacement performance; the 1994 paper's answer is yes, with no tuning required.
|
||
|
|
- The design splits the buffer into three structures: a main LRU queue for confirmed-hot pages, a first-in (probationary) queue for newly-seen pages, and a ghost queue that stores only the identifiers of recently-evicted pages (not their data).
|
||
|
|
- A page enters the probationary queue on first access; if it's re-referenced while still represented in the ghost queue, it gets promoted into the main queue.
|
||
|
|
- This design is specifically scan-resistant: a one-time sequential scan fills and drains the probationary queue without ever polluting the main hot-page queue.
|
||
|
|
- Per the source, 2Q's simplicity and effectiveness influenced PostgreSQL's own buffer-management design.
|
||
|
|
|
||
|
|
## Pros / strengths
|
||
|
|
|
||
|
|
- O(1), constant-overhead-per-access, no tuning parameters — directly addresses the "speed is important" constraint behind this entire research task, as a possible template if tai ever needs a real eviction policy rather than just tracking.
|
||
|
|
- Real production lineage (PostgreSQL) gives confidence this isn't just an academic curiosity.
|
||
|
|
|
||
|
|
## Cons / limitations / caveats
|
||
|
|
|
||
|
|
- 2Q's own main-LRU-queue component is itself expensive to make concurrent under high contention — this is exactly the weakness that `arxiv-2511-21958-clock2q-plus.md` (Clock2Q+) sets out to fix by replacing that component with a CLOCK-style structure.
|
||
|
|
- 2Q is an eviction-policy design for buffer pools; tai is not (yet) building eviction at all, only tracking — so 2Q is background context for a possible future phase, not something applicable today.
|
||
|
|
|
||
|
|
## Relevance to tai
|
||
|
|
|
||
|
|
Background/comparative context only for this research pass — explicitly not part of the current proposal (which is tracking-only, no eviction), but recorded here so a future eviction-policy decision doesn't have to rediscover 2Q as a candidate from scratch.
|
||
|
|
|
||
|
|
## Changelog
|
||
|
|
|
||
|
|
| Date | Change |
|
||
|
|
|---|---|
|
||
|
|
| 2026-10-09 | Initial dossier created. |
|