From 71f83b7e8cebc69a8c3ff079a2815173003159c9 Mon Sep 17 00:00:00 2001 From: "Joshua D. Drake" Date: Tue, 4 Aug 2026 17:36:17 -0600 Subject: [PATCH 1/2] docs: joins work; it is their speed that is unmeasured (#402 follow-up) #402 added "What this page does not measure" and it is right that the join-heavy shapes are absent. It leaves one thing ambiguous: it says nothing about whether joins work at all, so a reader can come away unsure whether a columnar table joins. That is a worse impression than the truth. Measured on a 200,000-row fixture: columnar joined to heap in either direction, columnar to columnar, inner, left with nulls, semijoin and anti-join, each returning results identical to the all-heap equivalent, and each of hash, merge and nested loop correct when forced. Column projection survives the join, so the columnar side reads only the columns the join and the target list need rather than losing the advantage at the join boundary. So the accurate claim is narrower and stronger than an absence: the speed is unmeasured, the correctness is not in question. #401 still owns the measurement. Co-Authored-By: Claude Opus 5 (1M context) --- docs/benchmarks.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/benchmarks.md b/docs/benchmarks.md index 1712f81..7c3ac37 100644 --- a/docs/benchmarks.md +++ b/docs/benchmarks.md @@ -625,6 +625,12 @@ to dimensions, and the selective-dimension-join pattern. Those are a large part what columnar storage is usually bought for, and this page says nothing about them. Not that we do badly on them. We have not measured them. See #401. +Joins themselves work. A columnar table joins a heap table in either direction, +and a columnar table, under hash, merge and nested-loop strategies, returning the +same rows as the all-heap equivalent, with column projection surviving the join so +the columnar side reads only the columns the join and the target list need. What is +absent is a measurement of how fast that is, not evidence that it works. + Read the conclusions below as being about single-table scan and aggregate work, because that is the evidence behind them. From f799a82deaa18c5862ac5dddc7dfbed8fff7d823 Mon Sep 17 00:00:00 2001 From: "Joshua D. Drake" Date: Tue, 4 Aug 2026 17:44:53 -0600 Subject: [PATCH 2/2] docs: split the joins sentence to the 25-word STE limit docs_style caught my own violation: 49 words against the 25-word limit test/ste_check.py enforces. The sentence was also badly built, stacking a coordination and two subordinate clauses on one subject. Four short sentences instead, same content: joins work in both directions and columnar to columnar, all three strategies return the all-heap rows, projection survives the join, and it is the speed that is unmeasured. Co-Authored-By: Claude Opus 5 (1M context) --- docs/benchmarks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/benchmarks.md b/docs/benchmarks.md index 7c3ac37..a4e9203 100644 --- a/docs/benchmarks.md +++ b/docs/benchmarks.md @@ -626,8 +626,8 @@ what columnar storage is usually bought for, and this page says nothing about them. Not that we do badly on them. We have not measured them. See #401. Joins themselves work. A columnar table joins a heap table in either direction, -and a columnar table, under hash, merge and nested-loop strategies, returning the -same rows as the all-heap equivalent, with column projection surviving the join so +and joins another columnar table. Hash, merge and nested-loop strategies all return +the same rows as the all-heap equivalent. Column projection survives the join, so the columnar side reads only the columns the join and the target list need. What is absent is a measurement of how fast that is, not evidence that it works.