zhuqi-lucas opened a new pull request, #11001: URL: https://github.com/apache/arrow-rs/pull/11001
## Which issue does this PR close? - Part of #10774. ## Rationale for this change `CachedArrayReader::consume_batch` reassembles each consumed span from the cached batches it touches: - span within **one** cached batch → `filter` alone, which shares the source data buffers — for byte-view columns, zero `buffer_index` rewriting (measured 0.058 ns/row) - span across **N** batches → filter each slice + `concat`, which rewrites every non-inline view's `buffer_index` (0.498 ns/row, 8.6x) On ClickBench Q12/Q25 shapes the multi-batch spans are 12.8% of calls but cover **50% of all rows**, and `concat_byte_view` dominates the cache's profile (the 5% flagged in #10774). Per the discussion there, single-pass kernel replacements (`interleave`, index-based and run-based gathers, and the `coalesce` machinery) all measured slower — at ~80% selectivity nothing beats filter's run-based bulk copy — so this PR makes the multi-slice path *rare* instead of faster. ## What changes are included in this PR? Cache the whole row group as a single batch when all of the following hold, otherwise keep `batch_size` (today's behavior): 1. **The filter has one predicate.** With several, later producers read under the selection refined by earlier predicates; coarse batches then expand each fetch to whole-row-group granularity, decoding rows the selection skipped (measured ~2x regressions on multi-predicate queries Q22/Q36 with a naive global multiplier). 2. **At least one cached column is BYTE_ARRAY.** Fixed-width concat is a plain memcpy with nothing to save, and the larger one-shot decode allocations measurably hurt (Q1 +20% with the naive multiplier). 3. **Cached columns fit in half the cache budget** (uncompressed), so coarser entries cannot start failing inserts, which pushes consumers onto the re-decode fallback at whole-row-group granularity (this compounds on Q22, which already sees ~11k rejected inserts per session today). Each gate corresponds to a regression observed when testing an unconditional granularity increase; with the gates, slice counters show exactly the intended targeting (Q12: multi-slice calls 12.8% → 0; Q1/Q22/Q36: unchanged). ## Are these changes tested? Existing parquet `--lib` suite: 1401 passed (the one failure, `test_int96_interop`, is a missing `parquet-testing` file, unaffected by this change). Local timing is too noisy on my machine to quote; requesting the benchmark bot below. Back-to-back runs with exact slice counters showed async/Q12 −14% at whole-row-group granularity with multi-slice reassembly eliminated. ## Are there any user-facing changes? No API changes. The predicate cache may hold the same data in fewer, larger entries for single-predicate scans over string/binary columns; peak cached bytes are unchanged (gated to half the budget), but eviction/accounting granularity is coarser for those scans. -- 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]
