Skip to content

Say that the benchmark page measures no joins at all #402

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jdatcmd merged 1 commit into from
Aug 4, 2026
Merged

Say that the benchmark page measures no joins at all #402

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 21 additions & 5 deletions docs/benchmarks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Loading