Defer chunk reader construction until after pruning

[Bardakor]

Rationale for this change

A selective scan can prune almost the whole file with zone maps, but the current evaluation path still materializes readers and filter futures for every chunk before that pruning result is known. On the reproducer in #9449 this makes construction cost scale with total chunk count even when the number of selected rows stays fixed.

• Closes: Selective filter cost scales with total chunk count, not with rows selected #9449

What changes are included in this PR?

• Defer ZonedReader data-child pruning until the zone-map mask has resolved.
• Pass the already-pruned mask into the data child so ChunkedReader can skip fully excluded chunks.
• Avoid constructing chunk readers during pruning for chunks whose input mask is already all false.
• Make chunk filter evaluation lazy: resolve each chunk's input mask before constructing its reader or its downstream array future.
• Add a regression test using a nested chunked layout backed by missing segments. An all-false filter mask must complete without touching those segments; the old eager path would attempt to evaluate them and fail.

No public API changes.

Testing

I could not run the Rust test suite locally in the current execution environment because it does not provide a Rust toolchain. This PR is opened as a draft so the repository CI can validate formatting, compilation, and tests before it is marked ready.

AI assistance

I used ChatGPT/Codex to inspect the issue and reader lifecycle, implement the lazy evaluation changes, and construct the regression test. I reviewed the resulting diff and the mask semantics before opening this draft PR.

[codspeed-hq]

Merging this PR will degrade performance by 0.36%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 3 improved benchmarks
❌ 3 regressed benchmarks
✅ 1998 untouched benchmarks
⏩ 89 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	slice_dict_tight_loop[10000]	687 µs	805.4 µs	-14.7%
❌	WallTime	words_gather_scalar[65536]	8.3 µs	9.4 µs	-12.23%
❌	Simulation	slice_primitive_tight_loop[10000]	421.4 µs	476.5 µs	-11.58%
⚡	Simulation	take[small_m/shuffled/primitive/nonnull/chunks=16384/indices=16]	1.2 ms	1 ms	+15.72%
⚡	Simulation	cold_misaligned[(64, 256)]	5 ms	4.4 ms	+14.03%
⚡	Simulation	compress_fsst[(1000, 64, 8)]	1.2 ms	1 ms	+12%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing Bardakor:agent/lazy-pruning-evaluation (b529b37) with develop (82cfea7)}

Footnotes

1. 89 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[myrrc]

The comment in this PR says:

I could not run the Rust test suite locally in the current execution environment because it does not provide a Rust toolchain. This PR is opened as a draft so the repository CI can validate formatting, compilation, and tests before it is marked ready.

Vortex contributing guidelines permit LLM-generated code as long as the author verifies the result. The section above implies to me you didn't verify the result or the commit message.

I'm therefore closing this PR.