feat(bench): Group A workloads — W2..W6 (sub-phase 9.2)

[joaoh82]

Summary

Sub-phase 9.2 of docs/benchmarks-plan.md. Stacks on top of #102 (9.1 harness + W1) to land the OLTP-baseline workloads:

ID	Shape	Status
W2	Range scan — WHERE secondary >= ? AND <= ?, 100/1k/10k width buckets	✅
W3	Bulk insert — BEGIN; INSERT…×100k; COMMIT	✅
W4	Single-row insert — auto-commit per row on a 1k-row preloaded table	✅
W5	Mixed OLTP — 50/50 SELECT-by-PK + UPDATE-by-PK on a 100k-row table	✅
W6	Secondary-index lookup — WHERE secondary = ? (unique probes)	✅

Smoke-run numbers (M1 Pro, criterion --warm-up-time 1 --measurement-time 1-2 --sample-size 10)

Workload	SQLRite	SQLite (rusqlite, WAL+NORMAL)	Ratio
W1 read-by-PK	~19 µs	~2.4 µs	~8×
W2 range-100	~36.6 ms	~60 µs	~610×
W2 range-1k	~32.2 ms	~594 µs	~54×
W2 range-10k	~33.8 ms	~6.5 ms	~5×
W3 bulk-100k	~1.35 s	~206 ms	~6.6×
W4 single-insert	~7.34 ms	~10.9 µs	~673× ⚠️
W5 mixed OLTP	~71.1 ms	~12.3 µs	~5,800×
W6 index lookup	~14.6 µs	~3.1 µs	~5×

The W2 ratio collapses as the matching set grows — SQLite scales with the result-set size; SQLRite full-scans the table in constant time regardless of width. That's because the engine's tiny optimizer (docs/supported-sql.md:210) only probes the index on <col> = <literal> shape — range predicates fall back to full scan. A future range-scan optimizer is the roadmap unlock.

Plan-spec adherence

• W2 uses >= ? AND <= ? instead of BETWEEN x AND y — SQLRite doesn't ship BETWEEN yet (it's in supported-sql.md's "Not yet supported" list). Semantically equivalent; both engines parse + execute it cleanly. Bumping to BETWEEN once SQLRite supports it = W2.v2.
• Q8 versioning preserved — every workload's WorkloadId.version is v1. JSON envelope tags every sample with W{n}.v{v}.
• Q3 SQLite tuning honored — driver still applies the WAL + synchronous=NORMAL + 64 MB cache + temp_store=MEMORY profile from 9.1.

W4 100× heuristic — investigation follow-up filed

The plan's exit criterion for 9.2:

If W4 shows >100× gap, file a follow-up to investigate the commit path before moving on. (Investigation, not a gate — the gap is informational.)

W4 is at ~673× and W5 (which amplifies the same root cause across a 100×-larger preload) is at ~5,800×. Filed SQLR-18 — "Investigate W4 single-row INSERT gap (~673× vs SQLite)" — informational, not a release gate. Likely culprit per the existing project conventions doc is the bottom-up B-tree rebuild on every COMMIT; the task spec lists a flamegraph + roadmap-cross-link plan.

Also filed SQLR-17 — "Investigate desktop-build CI hang on Tauri Linux deps step" for the 39-min apt-get hang seen on the 9.1 PR's CI run, unrelated to this work.

Methodology choices documented in code

• W3 uses iter_batched(BatchSize::PerIteration) with a per-sample counter so SQLRite's WAL sidecar from one sample doesn't collide with the next. sample_size(10) so a single-driver run finishes in minutes.
• W4 preloads 1,000 rows in one transaction before timing starts. Without that, the first iters hit a near-empty table and later iters hit a iters_so_far-sized table — SQLRite's O(N) bottom-up rebuild would create a steep ramp through the bench window. Preload puts the table at a stable size.
• W5 alternates SELECT/UPDATE deterministically (even iters SELECT, odd iters UPDATE) so the 50/50 mix is repeatable across runs.

Test plan

• cargo fmt --all -- --check clean
• cargo clippy -p sqlrite-benchmarks --all-targets clean
• Full CI-equivalent: cargo build / test / doc --workspace --exclude {desktop,python,nodejs,benchmarks} green
• cargo test -p sqlrite-benchmarks — 5 tests pass (4 inliner + 1 ymd round-trip)
• Smoke cargo bench -p sqlrite-benchmarks --bench suite -- --warm-up-time 1 --measurement-time 1-2 --sample-size 10 runs all six workloads end-to-end on both engines
• Aggregator post-processes the criterion output into a 14-row JSON envelope
• W2 / W3 / W4 / W5 / W6 correctness gates pass on both drivers

Follow-ups

• SQLR-18 — flamegraph the W4 hot path on SQLRite; cross-link to the roadmap entry for "Possible extras → Alternate storage engines."
• SQLR-17 — only act if the desktop-build apt hang recurs.
• 9.3 — Group B workloads (W7 aggregate, W8 GROUP BY, W9 INNER JOIN). Exercises the SQLR-3 (GROUP BY/aggregates) + SQLR-5 (JOIN) surface that landed in v0.7.0 / v0.8.0.
• Prepared-statement support in SQLRite is the natural unlock for W1's parse-cost-dominated band; would shrink W1/W6/W2-100 ratios. Post-9.6.

References

• Parent task: SQLR-16
• 9.1: #102
• Plan: docs/benchmarks-plan.md
• Code: benchmarks/src/workloads/

🤖 Generated with Claude Code