feat: implement take for canonical sparse Union arrays

[connortsui20]

Rationale for this change

• Progress towards Tracking Issue: Add DType::Union #7882

take on a UnionArray hit a todo!(), both in the parent-reduce path and in dictionary execution.

What changes are included in this PR?

Registers TakeReduce for Union, the naive way: take the type IDs, take every sparse child, reassemble. Sparse children are row-aligned with the union, so a gather has to visit all of them and take costs O(variants * indices). Fixing that needs the dense encoding, which is still open on the tracking issue.

The nullability split is the part worth reviewing. The type IDs child carries the union's validity, so it is gathered with the original indices and a null index becomes an outer union null. The children are gathered with the null indices filled with zero, which keeps each child's dtype exactly as the variant schema declares it. Struct splits its validity and its fields the same way.

Also adds UnionArray::constant, because take short-circuits an empty source into a constant null array before the union ever sees it. That unblocks two adjacent TODOs: canonicalizing a constant Union, and UncompressedSizeInBytes over one.

Notes

benches/take_union.rs lives in the vortex crate, which already depends on both vortex-array and vortex-sparse, and it compares two shapes of the same union of i64, utf8, and list<i64>. Rows are skewed 98% integers to 1% strings and 1% lists, the distribution the sparse layout exists for. dense_children materializes every child at the union's length. compressed_children keeps the dominant integer child canonical and stores each rare child as a SparseArray, which is what a compressor produces.

Compressed children turn out to be slower to take, not faster. 100k rows, 128 indices:

	dense children	compressed children
non-nullable indices	11.01 µs	36.61 µs
nullable indices	27.21 µs	46.32 µs

The cost is in Patches::take. With 1000 patches against 128 indices the ratio stays above PREFER_MAP_WHEN_PATCHES_OVER_INDICES_LESS_THAN, so every call takes the binary-search path, which is cache-miss bound at roughly 0.68 µs per index against 0.01 µs for a canonical child. That is a Patches cost rather than a union one. Union take multiplies it by the variant count.

This does not contradict the layout decision on #7882, which is about space. It does mean the take path gets no benefit from sparse children today, so it is worth a follow-up against Patches::take.

The two compressed_children cases run over the sub-millisecond budget the other microbenchmarks hold to. The gap only appears once a child's patch indices outgrow the cache: at 10k rows and 32 indices everything fits the budget and the gap collapses from 3.3x to 1.35x, which measures nothing. Landing them over budget is deliberate.

What APIs are changed? Are there any user-facing changes?

UnionArray::constant(scalar, len) is new. Three operations that used to panic now work: take on a union, canonicalizing a constant union, and uncompressed_size_in_bytes on a constant union.

[codspeed-hq]

Merging this PR will degrade performance by 0.44%

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 1923 untouched benchmarks
🆕 4 new benchmarks
⏩ 51 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	chunked_varbinview_opt_canonical_into[(10, 1000)]	4.4 ms	4.9 ms	-10.81%
⚡	Simulation	decompress[u64, (1000, 16)]	73 µs	65.7 µs	+11.13%
🆕	Simulation	take_union_compressed_children	N/A	462.6 µs	N/A
🆕	Simulation	take_union_compressed_children_nullable_indices	N/A	567.8 µs	N/A
🆕	Simulation	take_union_dense_children	N/A	222.1 µs	N/A
🆕	Simulation	take_union_dense_children_nullable_indices	N/A	339.3 µs	N/A

Tip

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

---

_{Comparing claude/union-take-impl-jsg9kj (dfa124c) with develop (a1057db)}

Footnotes

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

[connortsui20]

@gatesn the benchmark here is a bit naive, I will add compressing the sparse variants and seeing how that affects the benchmarks.

I still that this is something we would want to improve, but I guess we need to see who runs into perf bottlenecks first

Edit: Yeah as I expected, because we take against patches / sparse, we have to materialize a bunch of junk. I think this can be optimized though? @robert3005 do you have any thoughts?