[connortsui20]

Summary

The compression section of the versioning design still described per-edition scheme configuration as planned work, and said that the decimal scheme only declares the v1 wire ID. Since #10076, the decimal, bit-packing and frame-of-reference schemes pick their v1 or v2 variant from the allowed wire IDs. The section and the compression footnote of the compatibility page now describe that behavior, with the decimal scheme as the example. A v2 variant also writes the v1 ID, so a writer must allow both IDs to use it.

🤖 Generated with Claude Code

[codspeed]

Merging this PR will degrade performance by 1.37%

3 warnings, 1 note

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

⚠️ Unable to measure the execution of 2 benchmarks

These benchmarks measured no execution time, so their results are not comparable and count as unchanged. This usually happens when the compiler removes the code under test.

Prevent compiler optimizations

See affected benchmarks

⚠️ 20 benchmarks are 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

ℹ️ 40 benchmarks have no flamegraph

The flamegraph wasn't generated: the symbols of the profiling trace could not be resolved, because no information about the language frames was collected.

See affected benchmarks

⚡ 2 improved benchmarks
❌ 5 regressed benchmarks
✅ 2401 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	CPU Simulation	test_scan_filter_to_arrow_array[int_float]	3.5 ms	4.1 ms	-13.69%
❌	CPU Simulation	test_repeated_scan_filter[int]	2.4 ms	2.8 ms	-11.54%
❌	Walltime	bitpack_blocked_compress_avx2	6.7 µs	7.6 µs	-11.11%
❌	CPU Simulation	test_repeated_scan_filter[int_float]	3.4 ms	3.9 ms	-11.04%
❌	CPU Simulation	test_scan_filter_to_arrow_array[int]	2.5 ms	2.8 ms	-10.59%
⚡	CPU Simulation	bench_compare_primitive[(10000, 32)]	97 µs	72.9 µs	+33.05%
⚡	CPU Simulation	chunked_dict_primitive_canonical_into[f64, (1000, 1000, 10)]	191.7 µs	151.6 µs	+26.42%

Tip

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

---

_{Comparing ct/versioning-docs-refine (98119a5) with develop (3974ee0)}

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

[mhk197]

would remove the frame-of-reference reference bc it should support v2 bitpacked variant as well

[connortsui20]

Removed in 98119a5. The FoR child skipping the selected bit-packing variant is tracked as a bug in #10751, so the section now only says that child arrays go through the same compressor.

[mhk197]

is this necessary to include? This will change. Should just add an example.

[connortsui20]

Replaced the list with the decimal scheme as the one example in 98119a5, so the text does not go stale as more schemes gain variants.