…rf regression)

PR ClickHouse#100963 changed the per-output-block reserve in
MergeSorter::mergeBatchImpl from a constant to a sum over all input
chunks (capped at max_merged_block_size). The output block is already
bounded by max_merged_block_size, so for the common case (many input
chunks, each around max_merged_block_size rows) the sum saturates the
cap and reserves the same amount, but the summation walks the entire
chunks vector on every output block in front of the hot k-way merge
loop. This shows up as a measurable slowdown on the jit_sort perf test
(ARM Neoverse-V2, query 12: ORDER BY with LIMIT, around +18%
client_time).

Compute the estimate in O(1) instead. The k-way merge draws from all
chunks, so size the reserve as chunks[0].getNumRows() * chunks.size(),
capped at max_merged_block_size. This is one multiply with no per-block
loop, reserves closer to the actual merged output for the many-chunks
case, and is bounded by max_merged_block_size exactly as the sum form
was. For the regressing case both saturate the cap, recovering the time.

reserve() is a capacity hint only, so this does not affect results.

Reported and validated on ARM by egor-click in ClickHouse#106599. O(1) estimate
form suggested by 4ertus2 in review.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…rf regression)

PR ClickHouse#100963 changed the per-output-block reserve in
MergeSorter::mergeBatchImpl from a constant to a sum over all input
chunks (capped at max_merged_block_size). The output block is already
bounded by max_merged_block_size, so for the common case (many input
chunks, each around max_merged_block_size rows) the sum saturates the
cap and reserves the same amount, but the summation walks the entire
chunks vector on every output block in front of the hot k-way merge
loop. This shows up as a measurable slowdown on the jit_sort perf test
(ARM Neoverse-V2, query 12: ORDER BY with LIMIT, around +18%
client_time).

Compute the same estimate in O(1). chunks is not cleared until the
whole merge finishes, so the sum of input rows is constant across every
output block; sum it once in the constructor (which already iterates
the chunks) into total_input_rows, and reserve
min(total_input_rows, max_merged_block_size) per block. This is the
exact value the sum form reserved, computed once instead of per block,
so it neither under-reserves (as a bare chunks[0] estimate would for
many small chunks) nor over-reserves for uneven chunks (as a
chunks[0] * chunks.size() product would). For the regressing case it
saturates the cap, recovering the time.

reserve() is a capacity hint only, so this does not affect results.

Reported and validated on ARM by egor-click in ClickHouse#106599. O(1) estimate
suggested by 4ertus2 in review; bounding it by total input rows
(instead of the product) suggested by clickhouse-gh in review.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…f regression)

PR ClickHouse#100963 replaced the O(1) reservation min(chunks[0].getNumRows(),
max_merged_block_size) with a sum over all chunks (capped at
max_merged_block_size) computed on every output block, in front of the hot
k-way merge loop. The output block is already capped at max_merged_block_size,
and in the regressing jit_sort/12 case the input chunks are each about
max_merged_block_size rows, so the loop produced the same reservation while
adding per-block work. egor-click measured +18.73% on Neoverse-V2 (issue
ClickHouse#106599).

This restores the original O(1) form. chunks[0] is a single input chunk, so
the value never exceeds the rows the merge can emit (no over-reservation), and
there is no walk over chunks. reserve() is a capacity hint only, so the
merge-sort output is byte-identical regardless of the reserved size; for uneven
chunks the columns grow as needed. egor-click validated this form recovers the
regression on Neoverse-V2 (about -13.96% vs affected), whereas reserving the
saturated total-row sum did not.

Closes: ClickHouse#106599