Compress wide decimals into lower parts when the writer permits the v2 format

[mhk197]

Summary

Compress wide decimals into lower parts when the writer may emit vortex.decimal_byte_parts.v2. Under every current edition nothing changes, since none permits that format yet.

This is the last layer of the stack: #9834 (the array and its two wire formats) → #9928 (the compressor hands schemes the writer's permitted serialized IDs) → this PR.

Changes

DecimalScheme stays one scheme. It declares vortex.decimal_byte_parts as the format it always writes, since values that fit one signed part always serialize that way. In compress it narrows the decimal, splits it with split_decimal, and checks one thing before going further: if the split produced lower parts and the compression context does not permit the v2 format, the wide values are left canonical. Otherwise the most significant part and each lower part are compressed as children and assembled into a DecimalBytePartsArray.

The scheme now declares four children, the MSP plus up to three lower parts, so child indices are stable across both paths. MAX_LOWER_PARTS becomes public for that.

Behavior

Writer permits	Narrow values	Wide values
v1 only, every edition today	single-part array, written as v1	canonical decimal
v1 and v2	single-part array, written as v1	MSP plus lower parts, written as v2
unrestricted, editions disabled	same as above	same as above

Golden and trace snapshots are unchanged. A narrow decimal follows exactly the path it did before, since splitting a value that fits one part reuses its buffer as the MSP.

Testing

• Scheme tests: wide i128 and i256 inputs, nullable and not, split into one and three lower parts when v2 is permitted, and stay canonical when it is not. Narrow values never get lower parts and keep the frozen format under either mode. Extreme i256 values round-trip. Canonicalizing compressed output keeps the storage width. The scheme is present exactly when the frozen format is permitted, whatever the v2 setting.
• Writer tests: a struct of wide i128 and nullable i256 columns round-trips through a file when the session permits both formats. Under the core edition a pre-split input comes back canonical, and with v2 permitted its lower parts survive.

Follow-ups

• The CUDA preset needs to deny the v2 format, since the GPU kernel rejects lower parts. Today no edition permits v2 so the preset is safe, but that should land before one does.
• Edition placement for vortex.decimal_byte_parts.v2.

[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.

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

⚡ 6 improved benchmarks
❌ 1 regressed benchmark
✅ 2246 untouched benchmarks
⏩ 218 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	decompress[u64, (4000, 1024)]	71.7 µs	87.6 µs	-18.14%
⚡	WallTime	arrow_checked_add_u32_neon[16384]	20.3 µs	12.9 µs	+57.95%
⚡	Simulation	take_filter_list_slice_mask_sequential_indices[768, 50]	184 µs	141.8 µs	+29.78%
⚡	Simulation	take_filter_list_slice_mask_sequential_indices[256, 50]	185.4 µs	143.3 µs	+29.32%
⚡	Simulation	compact[(1024, 90)]	1.4 µs	1.3 µs	+12.98%
⚡	Simulation	compact[(2048, 90)]	1.5 µs	1.3 µs	+12.4%
⚡	Simulation	allocate_drop_arrow[0]	516.4 ns	462.3 ns	+11.72%

Tip

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

---

_{Comparing mk/dbp-v2 (78415c2) with mk/edition-aware-schemes (97cbf22)²}

Footnotes

1. 218 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 mk/edition-aware-schemes (d3526b5) during the generation of this report, so 7a50318 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩