Validate TPC-DS results against Vortex and Parquet

[joseph-isaacs]

Summary

Second of two stacked PRs adding TPC-DS to the SLT suite. Stacked on #9861 — review and merge that one first; this PR targets ji/tpcds-slt-plans, so its diff here shows only the results work.

#9861 adds the fixtures and asserts the 99 EXPLAIN plans. This one adds the result records, so the suite checks what the queries return as well as how they are planned, and reruns them against Parquet so both formats have to agree.

Changes

• results/q1.slt.no to results/q99.slt.no for both engines, from the same upstream queries in vortex-bench/sql/tpcds the plans already cover, run unchanged.
• tpcds.slt now includes results/*.slt.no alongside plans/*.slt.no, so each engine asserts results and plans against Vortex.
• parquet.slt per engine reruns the same result records against the original Parquet fixtures, so a Vortex-only result difference fails the suite.
• README: TPC-DS folds back into the general description of results/q*.slt.no and parquet.slt, replacing the interim "plans only for now" note from Add TPC-DS SLT plan tests #9861.

All 99 queries return the recorded rows on both engines and in both formats, and none of the upstream queries needed tie-breaking ORDER BY edits — unlike ClickBench, TPC-DS specifies a total order wherever it matters.

The diff is 198 generated result files plus two parquet.slt drivers, two one-line tpcds.slt changes, and the README paragraph.

Testing

The result records are themselves the new tests. I could not run them in this environment — the container has no flatc, so vortex-sqllogictest does not build here at all (failed to run flatc: No such file or directory); this is unrelated to the change. Verification is left to CI.

Earlier in this work, before the split, the combined suite passed on both engines and both formats.

🤖 Generated with Claude Code

https://claude.ai/code/session_01L57FHoJ15heJVNaqgRq7xB

---

Generated by Claude Code

[codspeed-hq]

Merging this PR will degrade performance by 4.03%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 2 improved benchmarks
❌ 3 regressed benchmarks
✅ 905 untouched benchmarks
⏩ 1505 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	filtered_owned_i64_avx2[OneNullInEight]	21.8 µs	26 µs	-16.11%
❌	WallTime	dict_canonicalize_gt_u8_neon[1000000]	487.5 µs	579.6 µs	-15.89%
❌	WallTime	mul_u32_nonnull_avx512	5.6 µs	6.2 µs	-10.45%
⚡	WallTime	dict_canonicalize_gt_u8_avx2[16000000]	7.9 ms	6.8 ms	+16.28%
⚡	WallTime	dict_canonicalize_gt_u8_avx2[1000000]	465.4 µs	420 µs	+10.82%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ji/tpcds-slt-results (7ca2bde) with ji/tpcds-slt-plans (c5957b6)²}

Footnotes

1. 1505 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on ji/tpcds-slt-plans (6fa1cf0) during the generation of this report, so fa2832b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩