feat(layout): compile segment scans, filters, concatenations, and packs to pipelines

[joseph-isaacs]

Summary

• Tracking: do not merge(scan): V2 planning, local IO coalescing, and shared segment cache on top of #10339 #10349

Stacked on #10391. Implements the pipeline compile hooks for the plans a struct of chunked columns lowers to, so such a plan runs end to end.

Changes

• SegmentScan reads and decodes one segment and keeps the rows its split selects. A Filter over a scan compiles to the same source, and over any other child keeps the selected rows of each batch in a stage. A flat layout lowers to a bare segment scan, as on develop.
• Concat builds only the chunks a split's mask selects a row of, so a chunk with no selected row is never read. It joins them with a source that drains its inlets in order. Rows inside one chunk are that chunk's rows, and no concatenation is built for them.
• Pack zips its fields' streams into structs, slicing at the boundaries the fields share. A single field is wrapped as it passes.
• Shared decoding. A segment several readers read is decoded once. One pass over the plan records the rows each segment is read for. The first reader builds one decoding pipeline that fans out into a port per reader, tagged by split, and a split's unclaimed ports are dropped when it finishes.

Tests port the node executor's cases with FIFO and LIFO delivery: views cutting every column at different places, unselected chunks never read, Pack streaming in row order, and a scan keeping its selection with and without a filter. They also check that several splits in one scan read each segment once, and that a finished scan holds no port.

Checks run: cargo clippy -p vortex-layout --all-targets --all-features -- -D warnings, cargo test -p vortex-layout --lib, cargo +nightly-2026-09-10 fmt -p vortex-layout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NWYmfHTFtaEdhdyd3u5hv3

[codspeed]

Merging this PR will regress 1 benchmark

⚠️ 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.

⚠️ 1 benchmark measured no execution time

Nothing ran under measurement, usually because the compiler removed the code under test. This result is not comparable, so it counts as unchanged.

Preventing compiler optimizations

• bench_compare_primitive[(10000, 2)]

⚠️ 13 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• random_i128[0.01]
• bench_compare_sliced_dict_primitive[(3333, 10000)]
• filter_run_end[len=4096_run=16_density=0.1]
• compress_fsst[(500, 16, 8)]
• multipolygon_mixed_validity
• decompress[u32, (1000, 256)]
• zstd_compress_string
• take_varbin
• pcodec_compress_f64
• decompress[u16, (4000, 256)]
• …and 3 more

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 2181 untouched benchmarks
⏩ 359 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	bitpack_blocked_compress_avx2	6.7 µs	7.6 µs	-11.98%
⚡	Simulation	cold[(16, 64)]	356.2 µs	309.7 µs	+15.02%

Tip

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

---

_{Comparing ji/exec-3-scan-concat-pack-nodes (a6f9c85) with ji/exec-2-exec-node (82fd9e5)²}

Footnotes

1. 359 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. ↩

2. No successful run was found on ji/exec-2-exec-node (06f2233) during the generation of this report, so 3867f7b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩