Aggregator support batch serialize

[guo-shaoge]

What problem does this PR solve?

Issue Number: close #9692

Problem Summary: Reduce virtual function call for key_serialize and key_string.

1. For key_serialized, batch-wise serialization/deserialization can reduce virtual function call (Also enable prefetch for key_serialized, because we can batch get hash after this pr)
2. For key_string, batch-wise sortKey can reduce virtual function call.

Workload: tpch-50g
Queries: same with #9679

  # --q5 Q3-1: key_serialized as group by method;  33/300M; HashMap with StringRef key
  "select /*+ mpp_1phase_agg() */ sum(l_discount), l_returnflag from lineitem group by l_returnflag, l_discount;"
  # --q6 Q3-2: key_serialized as group by method; 77M/300M; HashMap with StringRef key
  "select /*+ mpp_1phase_agg() */ sum(l_discount) as csum, l_returnflag from lineitem group by l_returnflag, l_discount, l_extendedprice having csum > 100;"


  # --q7 Q4-1: two_keys_num64_strbinpadding: 21/300M; HashMap with StringRef key
  "select /*+ mpp_1phase_agg() */ sum(l_discount) from lineitem group by l_returnflag, L_LINENUMBER;"
  # --q8 Q4-2: two_keys_num64_strbinpadding; 29.9M/300M; HashMap with StringRef key
  "select /*+ mpp_1phase_agg() */ sum(l_discount) as csum, l_partkey from lineitem group by l_returnflag, l_partkey having csum > 100;"
 

Query	nightly-20250205	opt-only_batch	opt-batch+prefetch	rate-opt_only_batch	rate-opt_batch+prefetch
Q3-1	1.79	1.54	1.58	13.97%	11.73%
Q3-2	7.45	6.13	4.9	17.72%	34.23%
Q4-1	2	2.07	2.09	-3.50%	-4.50%
Q4-2	5.34	4.48	3.57	16.10%	33.15%

Workload: clickbench
Queries: https://github.com/ClickHouse/ClickBench/blob/fdfdb5d94f2a668dce1f63d55498aa34510e4c9c/clickhouse/queries.sql#L11

Query	nightly-20250205	opt-only_batch	opt-batch+prefetch	rate-opt_only_batch	rate-opt_batch+prefetch
q10	242.6	234.7	233	3.26%	3.96%
q11	269.3	264.6	251.2	1.75%	6.72%
q13	879.1	851.2	830.1	3.17%	5.57%
q14	662.4	620.9	634	6.27%	4.29%
q16	1.53	1.42	1.4	7.19%	8.50%
q17	1.4	1.33	1.26	5.00%	10.00%
q18	4.55	3.81	3.59	16.26%	21.10%

NOTE:

1. nightly-20250205 commit: fe563a1; opt-batch commit: f20224a
2. For Q4-1/Q4-2, nightly key is two_keys_num64_strbinpadding. opt key is key_serialized.

What is changed and how it works?

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None

[yibin87]

Since we already have start_row here, do we need to resize to total size of key_columns[0]?

[guo-shaoge]

countSerializeByteSizeForCmp doesn't have start_row parameter. So we have to resize byte_size to the total size.

[yibin87]

So will byte_size be inited more than once here with different start_row parameter?

[guo-shaoge]

yes. Whenever a block needs to be aggregated (whether it is a new block or the result of a resize exception causing start_row to be greater than 0), the function countSerializeByteSizeForCmp will be called.

[guo-shaoge]

comment added

[yibin87]

Do we still need to keep the implementation of ChooseAggregationMethodFastPath?

[guo-shaoge]

Actually it can be removed, i will remove it.

[yibin87]

LGTM

[yibin87]

comments needed be updated

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yibin87

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [yibin87]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2025-02-28 01:46:22.415291328 +0000 UTC m=+579530.368449593: ☑️ agreed by yibin87.