fix(benchmarks): correct TPC-H benchmark SQL#21615
Conversation
|
cc @Omega359 |
|
Thank you, this looks reasonable to me. |
|
run benchmark tpch |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing fix/incorrect_tpch_queries (b232880) to 6db3899 (merge-base) diff using: tpch File an issue against this benchmark runner |
|
run benchmark tpch10 |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing fix/incorrect_tpch_queries (b232880) to 6db3899 (merge-base) diff using: tpch10 File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagetpch10 — base (merge-base)
tpch10 — branch
File an issue against this benchmark runner |
comphead
left a comment
There was a problem hiding this comment.
Thanks @kumarUjjawal it makes sense, thanks for bringing intervals back
Which issue does this PR close?
Rationale for this change
TPC-H query 11 was using a fixed
0.0001threshold in the HAVING clause. Per the TPC-H spec, this value must be0.0001 / SF.This means the benchmark query is only correct for scale factor 1. For larger scale factors the filter becomes too
strict, and for smaller scale factors it becomes too loose.
There are also few benchmark queries using fixed end dates where the spec uses
date + interval. Those are equivalent but using intervals matches the TPC-H query definitions more closely.What changes are included in this PR?
tpch_sf10.bench.sh.default scale factor of 1.
date ranges.
scale-factor parsing, and invalid scale factors.
Are these changes tested?
Yes
Are there any user-facing changes?
TPC-H benchmark query 11 now returns correct results when the scale factor is not 1.