hhhizzz opened a new issue, #10746: URL: https://github.com/apache/arrow-rs/issues/10746
### Is your feature request related to a problem or challenge? #10733 (fixed by #10735) was reachable only with Parquet predicate pushdown enabled. DataFusion defaults `datafusion.execution.parquet.pushdown_filters` to **false**, so neither project exercises the filter-driven sparse-fetch path in normal CI or in the standard benchmark runs: - arrow-rs CI does not run a query engine, so it never sets up the combination of pushdown + page pruning + predicate caching that real usage produces. - DataFusion CI and benchmarks run with pushdown off by default, so the path is not covered there either. The result is a configuration that is easy to hit in practice but that nothing tests. #10733 shipped in 59.2.0 and went unnoticed for roughly two weeks, and the same error class was already fixed once in #9301 (January 2026). ### Describe the solution you'd like A scheduled job that runs the **full** benchmark suites against arrow-rs `main` with predicate pushdown enabled, and asserts **correctness only** — not timing. The benchmark infrastructure needed for this already exists. The suites generate their own datasets, and `dfbench` already records per-query `success` and per-iteration `row_count` in its results JSON. So the job does not need a new test harness; it needs three things: 1. Patch arrow-rs `main` into DataFusion via `[patch.crates-io]` (DataFusion depends on arrow-rs, so the direction has to be inverted this way). 2. Run TPC-DS, TPC-H and ClickBench with `datafusion.execution.parquet.pushdown_filters=true`, one iteration each. 3. Compare the results JSON against a reference run. For the assertions, two checks cover the interesting failure modes: - **No query failures.** Every query reports `success: true`. This alone would have caught #10733, which showed up as three hard failures (TPC-DS q66/q75/q81), not as a subtle wrong answer. - **Row counts unchanged versus a reference run.** The natural reference is the same suite with pushdown **off**: same engine, same data, same queries, different read path. That gives a differential oracle without maintaining any golden results, and it catches the case where pushdown silently drops or duplicates rows rather than erroring. Running the whole suite rather than a targeted fixture is worth it here precisely because the bug came from an unanticipated combination: the value is in the variety of predicate shapes, selectivities, projections and page layouts that the suites already produce. Since the datasets and runners exist, the marginal cost is CI time rather than engineering time, which is also why this belongs on a schedule rather than on every PR. This is essentially automating what was already done by hand to validate #10735 (99/99 TPC-DS, 22/22 TPC-H, 43/43 ClickBench, row counts identical to the pre-fix baseline). Doing it by hand per PR does not scale, and nobody thinks to do it for a PR that looks unrelated to Parquet reads. ### Describe alternatives you've considered Extending the reader fuzz tests (filed separately as #TBD). That is cheaper, lives in this repo, and has a better bug-per-line ratio, so it is worth doing first. But fuzzing answers "we never tried this combination"; it does not answer "we didn't know this combination is the one users actually run". The parameter space still has to be chosen by hand, and the axis missing here — the predicate cache — was missing precisely because nobody connected it to the selection code. A run against real engine defaults is the backstop for that. A cut-down fixture was also considered: TPC-DS q81 needs only 4 SF10 tables (~120 MB) and reproduces #10733 deterministically in under a second. That is useful for local triage and for bisecting, but it only covers the one shape that is already known to be broken, which is the wrong thing to optimise for in a regression job. ### Additional context Related: #10733, #10735, #9301. -- 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]
