[connortsui20]

Summary

• Tracking Issue: Tracking Issue: Fix Canonical Decimal #10701
• Stacked on Decode DecimalByteParts into the canonical array or a decimal Widen #10905, and merges right after it

The DecimalByteParts scheme narrowed the decimal leaf itself with narrowed_decimal, which breaks the rule that every decimal leaf has the canonical width of its precision. narrowed_decimal also counted null slots, so a large value in a null slot could force lower parts that the precision does not allow, which #10905 now rejects. Choosing the split from the valid values of the canonical array avoids both problems.

Changes

Only an MSP without lower parts narrows, so the multipart output does not change. The v1 format cannot carry lower parts, so in v1 mode a precision 39 to 76 column whose values need more than 64 bits is written as a plain i256 leaf instead of a narrowed i128 one. That cost is accepted until vortex.widen and DecimalByteParts v2 enter core (#10733). The golden corpus pins this and the one other output change: ignoring null payloads gives decimal_null_slot_values an i32 MSP instead of i64.

API Changes

split_decimal takes an explicit lower-part count from lower_part_count, and narrowed_decimal is removed, since this scheme was its only caller.

[codspeed]

Merging this PR will degrade performance by 10.1%

1 warning

⚠️ 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 improved benchmark
❌ 5 regressed benchmarks
✅ 1768 untouched benchmarks
⏩ 47 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	CPU Simulation	missing_stats[16]	75.8 µs	93 µs	-18.49%
❌	CPU Simulation	bench_compare_varbin[(50000, 2)]	144.3 µs	173.4 µs	-16.81%
❌	CPU Simulation	encode_primitives[f32, (2000, 2)]	183.9 µs	211.8 µs	-13.17%
❌	CPU Simulation	bench_compare_sliced_dict_varbinview[(1000, 10000)]	92.4 µs	104.7 µs	-11.82%
❌	CPU Simulation	bench_compare_sliced_dict_varbinview[(9999, 10000)]	217.2 µs	244.8 µs	-11.3%
⚡	CPU Simulation	take_filter_primitive_small_uncached_random_mask_random_indices[4096, 10]	29.4 µs	25.7 µs	+14.67%

Tip

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

---

_{Comparing ct/dbp-scheme-canonical (616db28) with ct/dbp-canonical-decode (490ca09)}

Footnotes

1. 47 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]

I have been redesigning this, so this is no longer the change I want to make.