[connortsui20]

Tracking Issue: #10701

Stacked on #10946. It needs only decimal children in Widen, so it can merge before the rest of the decimal Widen stack, and it has no release gate.

Summary

Arrow exports every decimal up to precision 38 as Decimal128, but the exporter first executed its input to the canonical DecimalArray. A decimal Widen at precision 18 or less therefore copied its values twice, once into the canonical i64 width and again into i128. After #10905, every DecimalByteParts column with a narrow MSP decodes to a Widen, so this is the common export path for decimals that DataFusion reads from a file.

With this change, exporting widen_i32_p18 costs the same as exporting the canonical array (27.12 µs, down from 42.06 µs).

Changes

The exporter stops at a Widen and converts its child straight into the Arrow width, with the precision and scale of the logical dtype. The converters take the logical dtype separately from the values, so the export never builds a DecimalArray whose dtype is wider than its values, which CD8a will forbid. Struct, list, dictionary and run-end children reach the same exporter. Above precision 18 the canonical width is already i128, so those exports don't change.

When a child is stored wider than the Arrow width, the export narrows it. A null row whose value didn't fit used to fail the whole export. Narrowing now skips null rows and writes zero into them, as copy_to_canonical_width does, which also fixes the same failure for a plain DecimalArray.

The tests check that a Widen export equals the canonical export at the largest precision of each child width, for every Arrow decimal type the parent precision fits, with garbage in the null rows.

Benchmark results (Apple M4, medians)

cargo bench -p vortex-arrow --bench to_arrow -- decimal_export, 100,000 rows exported to Decimal128. Before is the benchmark commit of this PR and after is its tip, so the comparison isolates this layer. Other jobs shared the machine during the runs.

case	before	after
widen_i32_p18	42.06 µs	27.12 µs
widen_i64_p38	31.16 µs	27.16 µs
canonical_i64_p18	28.24 µs	27.04 µs

widen_i32_p18 is the case this PR changes. widen_i64_p38 and canonical_i64_p18 copy once both before and after, so they are controls.

API Changes

No public API changes. Exporting a decimal stored wider than the Arrow width no longer fails on a null row whose value does not fit.

[codspeed]

Merging this PR will not alter performance

2 warnings

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ 1 benchmark is dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

✅ 2360 untouched benchmarks

---

_{Comparing ct/widen-arrow-export (dacf961) with ct/decimal-widen (fdf9ac2)}