You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@datafusion.apache.org by "adriangb (via GitHub)" <gi...@apache.org> on 2026/06/11 22:57:05 UTC
[PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
adriangb opened a new pull request, #22919:
URL: https://github.com/apache/datafusion/pull/22919
## Which issue does this PR close?
- Related to #11262 (predicate evaluation ordering). Extends the `predicate_eval`
suite added in #22704. No single issue closed.
## Rationale for this change
The `correlation` subgroup's existing cases (q70–q72) use two predicates of equal
cost and equal selectivity. For two conjuncts the evaluation cost of an order is
`cost(first) + selectivity(first) × cost(second)`, which is symmetric here — so
the two orders cost the same and correlation only affects the result cardinality.
These cases measure the *overhead* of an ordering system, but give it no
opportunity: nothing in the suite rewards (or even detects) correlation-aware
ordering.
This adds a case with real, measurable headroom that **only** joint statistics can
find. A cheap integer predicate (`c0 = 1`, ~30%) is a perfect proxy for three
string regexes on `s1`; a fourth regex on `s2` has the same ~30% selectivity and
similar cost but is independent. Marginally, the four regexes are
indistinguishable in any position. Conditionally — behind the proxy — the three
`s1` regexes keep every survivor while the `s2` regex still discards ~70%.
The query is written in the natural-but-pessimal order (the redundant regexes
grouped with their proxy, the informative one last). On an M-series laptop the
written order runs ~1.9x slower than the hand-optimal order `[c0, s2-regex,
s1-regexes...]` (16.4 ms vs 8.6 ms per iteration), so:
- an ordering system using *marginal* per-predicate statistics (or an
independence assumption) is blind to the difference — every ranking of the four
regexes looks equivalent;
- a system measuring the predicates' *joint* behaviour can reliably collect ~1.9x.
## What changes are included in this PR?
- `load/corrproxy.sql` — the correlated-proxy dataset (deterministic, generated
from `generate_series` like the existing datasets; `PRED_ROWS`/`PRED_FILL`
knobs as elsewhere).
- `queries/correlation/q73.sql`, `benchmarks/correlation/q73.benchmark` — the new
case, following the suite's existing conventions.
Run with: `BENCH_NAME=predicate_eval BENCH_SUBGROUP=correlation cargo bench --bench sql`
## Are these changes tested?
The suite's shared template asserts the query returns rows; the case runs green
locally alongside q70–q72.
## Are there any user-facing changes?
No — benchmark-only.
🤖 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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "kosiew (via GitHub)" <gi...@apache.org>.
kosiew commented on code in PR #22919:
URL: https://github.com/apache/datafusion/pull/22919#discussion_r3426459967
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
Review Comment:
Small readability suggestion: the proxy condition `(value * 7) % 100 < 30` is repeated four times here.
It might be worth factoring it into a CTE or subquery and reusing a `proxy` boolean or int expression. That would make the intended perfect-proxy invariant more explicit and reduce the chance of drift if the threshold changes later.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "kosiew (via GitHub)" <gi...@apache.org>.
kosiew commented on code in PR #22919:
URL: https://github.com/apache/datafusion/pull/22919#discussion_r3426459967
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
Review Comment:
Small readability suggestion: the proxy condition `(value * 7) % 100 < 30` is repeated four times here.
It might be worth factoring it into a CTE or subquery and reusing a `proxy` boolean or int expression. That would make the intended perfect-proxy invariant more explicit and reduce the chance of drift if the threshold changes later.
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s1,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 13) % 100 < 30 THEN 'bbb' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s2
+FROM generate_series(1, ${PRED_ROWS:-1000000});
Review Comment:
I think this needs a tweak before the benchmark can serve as the correlation headroom case.
The key invariant here is that the four regex predicates should be marginally indistinguishable, so only joint or conditional stats can prefer `s2` after `c0`. Right now the generated data breaks that invariant: `s1` is roughly twice as wide as `s2`, the three `s1` markers occur at different offsets, and `s2` only has one marker after the first filler.
That means a marginal cost estimator, or even runtime timing, could identify `regexp_like(s2, 'b.b')` as cheaper than most or all of the `s1` regexes without using joint stats. In that case q73 would no longer isolate correlation-aware ordering.
Could we make the regex predicates have comparable marginal evaluation cost before using this as the correlation headroom case? For example, the strings could be equal width with equal marker offsets per predicate, or `s2` and the `s1` markers could be padded and positioned so a marginal-only system cannot distinguish them.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "adriangb (via GitHub)" <gi...@apache.org>.
adriangb merged PR #22919:
URL: https://github.com/apache/datafusion/pull/22919
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "adriangb (via GitHub)" <gi...@apache.org>.
adriangb commented on code in PR #22919:
URL: https://github.com/apache/datafusion/pull/22919#discussion_r3448077383
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s1,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 13) % 100 < 30 THEN 'bbb' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s2
+FROM generate_series(1, ${PRED_ROWS:-1000000});
Review Comment:
Good catch — fixed in the latest push. The dataset now uses four columns of identical shape (`s1`/`s2`/`s3`/`s4`): each is the same width, holds a single marker at the same offset, and is matched by an equally cheap regex of the same ~30% selectivity. So the four regexes are now marginally indistinguishable in any position — neither a per-predicate cost estimate nor runtime timing can prefer one over another; only their joint distribution with the proxy can. Verified on 1M rows: equal widths (63), marginal selectivities all 0.30, and conditional-on-`c0` selectivity 1.0 for `s1`/`s2`/`s3` vs 0.30 for `s4`. Re-measured headroom is ~1.7x (16.5 ms vs 9.7 ms median).
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
Review Comment:
Done — the proxy condition (and the independent control) are now defined once each in a `WITH base` CTE as named booleans (`proxy`, `indep`) and reused, so the perfect-proxy / independence invariants have a single source of truth and cannot drift if a threshold changes.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "kosiew (via GitHub)" <gi...@apache.org>.
kosiew commented on code in PR #22919:
URL: https://github.com/apache/datafusion/pull/22919#discussion_r3426308958
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
Review Comment:
Small readability suggestion: the proxy condition `(value * 7) % 100 < 30` is repeated four times here.
It might be worth factoring it into a CTE or subquery and reusing a `proxy` boolean or int expression. That would make the intended perfect-proxy invariant more explicit and reduce the chance of drift if the threshold changes later.
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s1,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 13) % 100 < 30 THEN 'bbb' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s2
+FROM generate_series(1, ${PRED_ROWS:-1000000});
Review Comment:
I think this needs a tweak before the benchmark can serve as the correlation headroom case.
The key invariant here is that the four regex predicates should be marginally indistinguishable, so only joint or conditional stats can prefer `s2` after `c0`. Right now the generated data breaks that invariant: `s1` is roughly twice as wide as `s2`, the three `s1` markers occur at different offsets, and `s2` only has one marker after the first filler.
That means a marginal cost estimator, or even runtime timing, could identify `regexp_like(s2, 'b.b')` as cheaper than most or all of the `s1` regexes without using joint stats. In that case q73 would no longer isolate correlation-aware ordering.
Could we make the regex predicates have comparable marginal evaluation cost before using this as the correlation headroom case? For example, the strings could be equal width with equal marker offsets per predicate, or `s2` and the `s1` markers could be padded and positioned so a marginal-only system cannot distinguish them.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "kosiew (via GitHub)" <gi...@apache.org>.
kosiew commented on code in PR #22919:
URL: https://github.com/apache/datafusion/pull/22919#discussion_r3426459962
##########
benchmarks/sql_benchmarks/predicate_eval/load/corrproxy.sql:
##########
@@ -0,0 +1,30 @@
+-- Correlated-proxy dataset: a cheap integer predicate that is a perfect proxy
+-- for three string predicates, plus one independent string predicate.
+--
+-- c0 = 1 for ~30% of rows (cheap proxy)
+-- s1 contains 'aaa', 'ccc' and 'ddd' exactly where c0 = 1 (correlated)
+-- s2 contains 'bbb' for an independent ~30% of rows (independent)
+--
+-- Marginally, the four regex predicates are indistinguishable: similar cost,
+-- the same ~30% selectivity. Their *conditional* selectivities behind the
+-- proxy differ completely: after `c0 = 1`, the three s1 regexes keep every
+-- survivor (each re-tests the proxy's condition) while the s2 regex still
+-- discards ~70%. Only joint statistics can see that; an independence
+-- assumption prices all four regexes identically in every position.
+--
+-- PRED_FILL sets the filler width around each marker (a non-matching
+-- `regexp_like` must scan the whole value), and PRED_ROWS sizes the table.
+CREATE TABLE t AS
+SELECT
+ CASE WHEN (value * 7) % 100 < 30 THEN 1 ELSE 0 END AS c0,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'aaa' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ccc' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 7) % 100 < 30 THEN 'ddd' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s1,
+ repeat('q', ${PRED_FILL:-30})
+ || CASE WHEN (value * 13) % 100 < 30 THEN 'bbb' ELSE 'zzz' END
+ || repeat('q', ${PRED_FILL:-30}) AS s2
+FROM generate_series(1, ${PRED_ROWS:-1000000});
Review Comment:
I think this needs a tweak before the benchmark can serve as the correlation headroom case.
The key invariant here is that the four regex predicates should be marginally indistinguishable, so only joint or conditional stats can prefer `s2` after `c0`. Right now the generated data breaks that invariant: `s1` is roughly twice as wide as `s2`, the three `s1` markers occur at different offsets, and `s2` only has one marker after the first filler.
That means a marginal cost estimator, or even runtime timing, could identify `regexp_like(s2, 'b.b')` as cheaper than most or all of the `s1` regexes without using joint stats. In that case q73 would no longer isolate correlation-aware ordering.
Could we make the regex predicates have comparable marginal evaluation cost before using this as the correlation headroom case? For example, the strings could be equal width with equal marker offsets per predicate, or `s2` and the `s1` markers could be padded and positioned so a marginal-only system cannot distinguish them.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] bench: add correlated-proxy case to the predicate_eval suite [datafusion]
Posted by "adriangb (via GitHub)" <gi...@apache.org>.
adriangb commented on PR #22919:
URL: https://github.com/apache/datafusion/pull/22919#issuecomment-4761276969
@kosiew thanks for the review — addressed both points and rebased on latest `main`:
- **Marginal indistinguishability:** the dataset now uses four columns of identical shape (`s1`–`s4`) — equal width, one marker at the same offset, an equally cheap regex each — so a marginal cost estimator or runtime timing cannot tell the four regexes apart; only their joint distribution with the proxy can. Verified on 1M rows (equal widths 63, marginal selectivities all 0.30, conditional-on-`c0` 1.0 for `s1`/`s2`/`s3` vs 0.30 for `s4`).
- **Readability:** the proxy and independent conditions are factored into a `WITH base` CTE as named booleans.
Re-measured headroom: written vs hand-optimal `[c0, s4, s1/s2/s3]` is ~1.7x (16.5 ms vs 9.7 ms median). PR description updated. PTAL.
--
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: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org