APIs
Pagination: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick.
Reconstruct the unit’s core mechanisms — why offset scales with depth, why it drifts, what makes a keyset key valid, why cursors are opaque, and why exact counts are expensive — without looking back at the lesson.
- 01Why does LIMIT 20 OFFSET 200000 get slower the deeper you page, even though it always returns 20 rows?
- 02Explain result drift: why does an offset feed show duplicate and missing items, and why even on a small table?
- 03What two properties must a keyset sort key have, and what breaks if the key is not unique?
- 04Why expose an opaque cursor instead of the raw (created_at, id) keys, and what does the client do with it?
- 05What does keyset give up compared to offset, and when is offset still the right choice?
- 06Why is an exact total count expensive in Postgres, and what are the alternatives in order of preference?
If you reconstructed each answer from memory, you hold the unit’s spine: offset cost scales with depth because the engine reads and discards every prior row; offset drifts because position is not a stable address under writes; a valid keyset key is unique, stable, and index-backed, compared as a whole tuple; the cursor is opaque so the contract can evolve and clients can’t craft expensive seeks; keyset trades arbitrary page jumps for flat latency, which is why offset still fits bounded admin surfaces; and an exact count is an MVCC full scan, so estimate or probe with n+1 instead.