[mvanhorn]

Summary

Filling nulls panics when the replacement value is a lazy scalar. The failure reports that the fill value must be a constant or scalar. Execution required the fill argument to already be a constant and rejected it when that check found nothing. A lazy scalar, such as an unevaluated literal, becomes a constant only after it runs, so it took that failure path. The parent kernels demanded the same thing with vortex_expect, which panics when the fill child is not already constant.

Execution now evaluates a fill that is not already a constant until it becomes one, then reads the scalar. The parent reduce and execute kernels return no match when the fill child is not constant, leaving that case to execution. A fill that is still not a scalar afterward still fails with the constant-or-scalar error. Tests cover a lazy literal fill and a varying fill that the kernels decline.

cargo test -q --manifest-path vortex-array/Cargo.toml -p vortex-array passed the vortex-array library tests with 4351 passed, 0 failed, and 1 ignored.
That command passed the next test target with 77 passed, 0 failed, and 21 ignored.
That command passed the remaining test target with 1 passed and 0 failed.
That command finished the doctests.

Fixes #10543

Changes

Covered in the summary above.

API Changes

Uncomment this section if there are user-facing changes, such as a broken public API or a change in the behavior of an engine integration. A breaking change also needs the changelog/break label.
-->

AI was used for assistance.

[codspeed]

Merging this PR will degrade performance by 6.37%

⚠️ 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)]

⚠️ 16 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]
• test_scan_filter[int_float]
• test_scan_filter[int_str_float]
• decompress[u16, (4000, 256)]
• multipolygon_mixed_validity
• decompress[u32, (1000, 256)]
• take_varbin
• zstd_compress_string
• test_scan[int_str_float]
• pcodec_compress_f64
• …and 6 more

ℹ️ 40 benchmarks have no flame graph

The flamegraph could not be generated because we failed to resolve the symbols in the profiling trace. This happens when we fail to harvest information about language frames.

• test_repeated_scan[int]
• test_repeated_scan_filter[int]
• test_scan_to_arrow_array[int]
• test_scan_filter[int]
• test_scan_scalar_at[int_str]
• test_repeated_scan_scalar_at[int_str]
• test_scan_filter[int_float]
• test_scan_filter_to_arrow_array[int]
• test_scan_filter[int_str_float]
• test_repeated_scan_scalar_at[int_str_float]
• …and 30 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

⚡ 2 improved benchmarks
❌ 4 regressed benchmarks
✅ 2402 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌ ⚠️	Simulation	random_i128[0.01]	3.8 µs	4.7 µs	-19.08%
❌	Simulation	sum_v2_i64	194.2 µs	224.9 µs	-13.66%
❌	Simulation	sum_i64	194.7 µs	225.1 µs	-13.52%
❌	WallTime	bitpack_blocked_compress_avx2	6.7 µs	7.6 µs	-11.69%
⚡	WallTime	starts_with_avx2[8, VarBin]	46.6 µs	41.1 µs	+13.4%
⚡	Simulation	isolated_runs[u32, (16, 0)]	87.5 µs	78.6 µs	+11.33%

Tip

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

---

_{Comparing mvanhorn:fix/10543-fill-null-lazy-fill-values (3aa9df0) with develop (5fc5cb8)}

Footnotes

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