adriangb opened a new pull request, #25032: URL: https://github.com/apache/datafusion/pull/25032
## Which issue does this PR close? - Part of #22883 - Related to #11262 - Prequel split out of #22698: these are the benchmark-suite additions from that PR, carried on their own so they can land (and be run) independently of the adaptive-filter work. ## Rationale for this change The `predicate_eval` suite (the conjunctive-filter microbenchmarks added for adaptive predicate ordering in #11262) was missing two shapes that distinguish evaluation strategies for AND chains: 1. **An expensive-selective conjunct written *before* a cheap-unselective one.** The suite already had the reverse (`costsel` q03: cheap `c0 < 90` at ~90% first, expensive `regexp_like(s, 'rare')` at ~0.1% second). Without the mirror shape there is no case in the suite where the as-written order is already the optimal one, so the suite cannot tell "reordered well" apart from "reordered at all". It also exercises a distinct code path: measuring a *cheap* conjunct on the small survivor batch left after pre-selection by an expensive one, rather than measuring an expensive conjunct on a full batch. 2. **A many-column table.** Every existing `cardinality` query runs over the 16-column `ints` dataset, so the cost of materializing a filtered batch per level is small and roughly constant across the suite. Re-running the k = 8 predicate over a 64-column table separates the cost of *evaluating* the conjuncts from the cost of *filtering the batch* at each level, which is what per-level batch filtering actually pays for on wide inputs. ## What changes are included in this PR? Five new files, all under `benchmarks/sql_benchmarks/predicate_eval/`: - `queries/costsel/q04.sql` + `benchmarks/costsel/q04.benchmark` — `costsel_q04_expensive_selective_then_cheap_unselective`: the mirror of q03. Same two predicates, written the other way round, so the as-written order is already the best one. Together q03/q04 bracket a reorderer's behaviour when cost and selectivity point the same way. - `queries/cardinality/q34.sql` + `benchmarks/cardinality/q34.benchmark` — `cardinality_q34_k8_wide64`: q32's k = 8 predicate (seven ~90% compares followed by one ~5% compare) run over the new 64-column dataset. - `load/ints_wide.sql` — `ints` widened from 16 to 64 Int64 columns. It extends `ints.sql`'s multiplier sequence rather than replacing it: `c0..c15` keep exactly the same multipliers (all coprime to 100, so residues stay uniform and columns stay mutually decorrelated), which means q34's predicate has exactly the same hidden selectivities as q32's. Only the width of the batches flowing through the filter changes. No Rust, config, or documentation changes — the suite discovers the new `.benchmark` files automatically. ## What is the testing strategy for this PR? No unit tests: these are benchmark definitions, not library code. Verification is that the suite still parses and both new queries run and produce a result row. On this branch (i.e. on top of `main`, with no other changes): ``` $ cargo run --release --bin benchmark_runner -- predicate_eval --subgroup costsel -i 1 -r 100000 predicate_eval/costsel_q01_regexp_selective_last/costsel iteration 0: 1.6 ms, 1 rows predicate_eval/costsel_q02_regexp_selective_first/costsel iteration 0: 0.5 ms, 1 rows predicate_eval/costsel_q03_cheap_unselective_then_expensive_selective/costsel iteration 0: 0.4 ms, 1 rows predicate_eval/costsel_q04_expensive_selective_then_cheap_unselective/costsel iteration 0: 0.4 ms, 1 rows $ cargo run --release --bin benchmark_runner -- predicate_eval --subgroup cardinality -i 1 -r 100000 predicate_eval/cardinality_q30_k2/cardinality iteration 0: 0.6 ms, 1 rows predicate_eval/cardinality_q31_k4/cardinality iteration 0: 0.5 ms, 1 rows predicate_eval/cardinality_q32_k8/cardinality iteration 0: 0.9 ms, 1 rows predicate_eval/cardinality_q33_k16/cardinality iteration 0: 1.4 ms, 1 rows predicate_eval/cardinality_q34_k8_wide64/cardinality iteration 0: 0.8 ms, 1 rows ``` The two new lines are `costsel_q04_expensive_selective_then_cheap_unselective` and `cardinality_q34_k8_wide64`. That q34 and q32 have identical selectivities was checked separately: both return `count(*) = 5000` at `PRED_ROWS=100000`. ## Are there any user-facing changes? No. Benchmark definitions only; nothing in this PR is part of any public API or affects query execution. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
