From a6771ce437339b59697b53205baac005a3a5a878 Mon Sep 17 00:00:00 2001 From: "Joshua (D) Drake" Date: Tue, 4 Aug 2026 17:22:51 -0600 Subject: [PATCH] Say that this page measures no joins at all The conclusions generalise to "analytics". The evidence does not. All eight TSBS queries are a scan, a filter and an aggregate over one relation: $ grep -lci '\bjoin\b' queries/tsbs/*.sql | wc -l 0 $ grep -hiE '^\s*FROM' queries/tsbs/*.sql | sort | uniq -c 8 FROM %T Star schemas and dimension joins are a large part of what columnar storage is bought for, and this page has nothing to say about them. Read as written, it invited a reader to carry a single-table result into a workload we have never run. A new section states the gap before the conclusions rather than after them, and says plainly that the absence is unmeasured rather than bad. The two conclusions that said "analytics" now say which analytics, and the closing line notes that whether the result survives a join is open. #401 covers measuring it. This is the disclosure, which should not wait for the measurement. --- docs/benchmarks.md | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/docs/benchmarks.md b/docs/benchmarks.md index 6b47eb1..1712f81 100644 --- a/docs/benchmarks.md +++ b/docs/benchmarks.md @@ -614,16 +614,32 @@ both are larger than anything in it: The point lookup is the one number that moved the wrong way, and it moved a long way. See the note above it. +## What this page does not measure + +**Every query on this page reads one table.** The TSBS workload is time-series +shaped. All eight of its queries are a scan, a filter and an aggregate over a +single relation. None of them joins. + +So the join-heavy analytical shapes are absent: star schemas, fact tables joined +to dimensions, and the selective-dimension-join pattern. Those are a large part of +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. + +Read the conclusions below as being about single-table scan and aggregate work, +because that is the evidence behind them. + ## Reading the results -Columnar wins on analytic shapes: aggregates answered from metadata, filtered -aggregates that minimum, maximum and bloom skipping can prune, wide-table -projections, and index-only covering scans. The size reduction comes mostly from +Columnar wins on the analytic shapes measured here. Those are aggregates answered +from metadata, filtered aggregates that minimum, maximum and bloom skipping can +prune, wide-table projections, and index-only covering scans. The size reduction comes mostly from the encoding layer before zstd. Vectorization adds a large further speedup on aggregates, and storing a table sorted on its range key improves skipping. Heap is better for single-row fetches and for deletes, and by a large margin in both. On a table with deletes, the aggregate advantage is not present until a vacuum runs. -Columnar is the wrong choice for write-heavy OLTP and the right choice for -scan-heavy and aggregate-heavy analytics over wide, append-mostly tables. +Columnar is the wrong choice for write-heavy OLTP. It is the right choice for +scan-heavy and aggregate-heavy analytics over wide, append-mostly tables, on the +single-table shapes measured here. Whether that holds once a join is involved is +an open question and not a claim this page supports.