A 1.7% smaller page, three times faster
A materialisation step in the pipeline compiler walked a million-row table in pages and took longer than it should. The obvious fix was to parallelise the walk. The right fix was a number I hadn't looked up.
The sweep
One million rows, 29 columns, a single operator that reads the table page by page and writes the result. I swept the page size from 10,000 rows to 1,000,000 and timed the operation: 4.69 seconds at the smallest page, 0.51 at the largest. Bigger pages, fewer round-trips, faster — unsurprising, and not yet useful, because a million-row page is not a page.
The number underneath
The store is DuckDB, and DuckDB organises a table into row groups of 122,880 rows. A page that does not align with that boundary makes the engine touch a row group it will mostly discard. So I re-ran the sweep at multiples of the row group: 122,880 rows took 1.19 seconds; 491,520 took 0.51 — the same as the million-row page, at half the memory.
The decisive pair was 245,760 against 250,000. Same page count. The aligned page is 1.7% smaller, and about three times faster. No amount of intuition about "bigger pages" predicts that; only knowing the storage unit does.
Why not parallelism first
The note I wrote into the spec at the time is in capitals in the original, because I'd been about to make the mistake: do not reach for parallelism as a first move. Two reasons. Parallelising a misaligned walk multiplies the waste along with the work. And the step that followed the walk — the store's checkpoint, which merges the write-ahead log into columnar files — was 31% of the destination's wall-clock and serial by design; parallel readers would have queued behind it. Aligning the page cost one afternoon and one constant. Parallelism would have cost a week and delivered less.
The general version
Every storage engine has a unit — a block, a row group, a stripe, a segment — and every access pattern is either aligned to it or paying for it. Before tuning anything above the storage layer, find the unit and check the alignment. It is the cheapest optimisation there is, and it is invisible from the application's side of the API, which is exactly why it gets missed.
The constant now lives in the compiler with a comment naming where it came from and when it was measured — the same habit as the checkpoint benchmark: record the number, record the reason, and record what you ruled out.
Measurements from a materialisation-cost spec written in August 2026; single host, serial execution, timings are wall-clock per operation.