From 79c2686532b5f88ed49544197fc3c7ae7f394ef9 Mon Sep 17 00:00:00 2001 From: Sahil Kalgutkar Date: Fri, 28 Aug 2026 18:56:07 -0400 Subject: [PATCH] Say that the benchmark table is one run, not a fixed result Re-running it on the same machine moves the speedups by tens of percent, so presenting them without that caveat invites a reader to treat a sample as a guarantee. The row-group counts are stable and are the number actually worth reading. --- README.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index a522d3d..360062c 100644 --- a/README.md +++ b/README.md @@ -185,8 +185,13 @@ join 4999 1.22ms 123.6x 151.20ms 2 read The three-figure numbers are zone-map pruning: reading 3 row groups instead of 62. The 4.5x on a full aggregate is projection pushdown on its own — one column -chunk per row group instead of four. Reproduce with `cargo run --release -- -bench`. +chunk per row group instead of four. + +That table is one recorded run, not a fixed result: `cargo run --release -- +bench` regenerates it, and the ratios move by tens of percent between runs and +between machines. The row-group counts do not, which is why they are the number +worth reading — they are a property of the data and the predicate rather than of +the hardware. `EXPLAIN ANALYZE` reports the same counters per operator: