Performance
Batching: 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 material stick.
Reconstruct the unit’s spine — the fixed-cost model, the two-trigger window, the speedup math, why compression needs batching, the overflow policies, and the batch-boundary attack surface — without looking back at the lessons.
- 01Why does batching help, what is the cost model, and where does it NOT pay off?
- 02Derive the speedup formula and explain where it goes to N versus 1.
- 03Why does a batching window need both a max-size and a max-wait, and what does which-trigger-fires diagnose?
- 04Walk the Postgres ingestion rungs and explain why compression needs batching first.
- 05A producer outruns the consumer and the bounded queue is full. Compare block, drop, and spill-to-disk, and say how you choose.
- 06Why is per-batch idempotency unsafe, and how does CVE-2023-34455 generalize the batch-boundary security rule?
If you could reconstruct each answer from memory, you hold the unit’s spine: batching turns N·(F + V) into F + N·V and pays off only with a dominant fixed cost, queue depth, and latency slack; the two-trigger window (size for throughput, time for latency) is sized to the SLO and validated against replayed traffic; speedup goes to N when F dominates and to 1 when V does, break-even per item at F = V·n; Postgres climbs INSERT → multi-row → COPY and compression rides on top of fat batches; bounded queues pick block, drop, or spill as a product decision; and the batch boundary is an attack surface validated post-decompression and per-item.