TPC-H SF 0.2 · developer build (debug) · full 22-query run · 2026-08-31

Benchmarks

A pre-release developer run — not the reference benchmark.

QueryInnoDBRapidSpeedup
Q1 — pricing summary report 32.9 s 15.9 s 2.1×
Q2 — minimum cost supplier 1.4 s 3.1 s 0.45×
Q3 — shipping priority 33.4 s 4.9 s 6.9×
Q4 — order priority checking 5.1 s 5.2 s 0.98×
Q5 — local supplier volume 22.2 s 1.9 s 11.6×
Q6 — forecasting revenue change 12.0 s 2.4 s 5.1×
Q7 — volume shipping 106.1 s 2.4 s 45.0×
Q8 — national market share 56.4 s 5.8 s 9.8×
Q9 — product type profit measure > 150 s 38.7 s > 3.9×
Q10 — returned item reporting 9.2 s 1.7 s 5.4×
Q11 — important stock identification 56.6 s 0.9 s 60.9×
Q12 — shipping modes and order priority 16.6 s 5.3 s 3.1×
Q13 — customer distribution 5.3 s 3.5 s 1.5×
Q14 — promotion effect 15.2 s 2.2 s 6.9×
Q15 — top supplier 14.7 s 2.3 s 6.5×
Q16 — parts/supplier relationship 2.7 s 0.7 s 4.0×
Q17 — small-quantity-order revenue > 150 s 7.7 s > 19×
Q18 — large volume customer 15.9 s 5.0 s 3.2×
Q19 — discounted revenue 23.3 s 7.0 s 3.3×
Q20 — potential part promotion > 150 s 6.6 s > 22×
Q21 — suppliers who kept orders waiting 107.6 s 18.3 s 5.9×
Q22 — global sales opportunity 3.8 s 1.0 s 3.7×
All 22 queries > 990 s 142 s > 6.9×

This is a developer run at SF 0.2 on an unoptimized debug build, not the SF 10 reference configuration. Absolute latencies are inflated several-fold by the debug build; figures prefixed “>” are wall-clock lower bounds for the three queries that hit the 150 s per-statement cap — Q9, Q17 and Q20, all of them on InnoDB — so the aggregate ratio is a floor, not a ceiling. Read the ratios as directional only. Harness, dataset generation, and raw output are in heatwave-tpch. The reference SF 10 run is pending.

Run notes

Harness
run_tpch.sh, Q1–Q22, A/B per query in a single session
Scale
SF 0.2 (LINEITEM ≈ 1.2M rows)
Matrix
InnoDB with the legacy optimizer and the secondary engine off, versus Rapid with the hypergraph optimizer and use_secondary_engine=FORCED
Correctness
0 mismatches — every one of the 19 queries that completed on both engines returned a byte-identical result set. The other three went uncompared because InnoDB, not Rapid, ran out of time
Coverage
All 22 queries now complete on Rapid inside the cap; InnoDB fails to finish three of them
Wins
Rapid carries three queries InnoDB cannot finish inside the cap (Q9, Q17, Q20), and the scan/join/aggregate path wins uniformly — 9× to 61× on Q5, Q7, Q8, Q11, Q17 and Q20
Stability
Fixed since the previous run: the uncorrelated scalar subquery in Q11’s HAVING clause is now evaluated once rather than once per group. Q11 goes from a 150 s timeout to 0.9 s — a 60.9× win over InnoDB and the largest single swing in this run. Rapid’s total for the full sweep halves, 286 s to 142 s
Regressions
None against the previous run. Q2 remains the only query Rapid loses outright at 0.45×, and at 1.7 s absolute it reads as a low-priority planning artifact rather than an execution defect; Q4 sits at parity
Variance
Three passes over the sweep put Rapid’s total at 142.3 s, 141.0 s and 133.8 s — roughly ±5% run to run on this box, so per-query differences below that threshold are noise
Next
Close the Q2 planning gap, then a full SF 10 run on the reference node