POC Optimize near-unique string view group values#23384
Conversation
|
run benchmarks clickbench_partitioned |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing mark-near-unique-to-group-values (ae74b26) to f34a676 (merge-base) diff using: clickbench_partitioned File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usageclickbench_partitioned — base (merge-base)
clickbench_partitioned — branch
File an issue against this benchmark runner |
|
run benchmarks clickbench_partitioned |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing mark-near-unique-to-group-values (ae74b26) to f34a676 (merge-base) diff using: clickbench_partitioned File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usageclickbench_partitioned — base (merge-base)
clickbench_partitioned — branch
File an issue against this benchmark runner |
Which issue does this PR close?
Rationale for this change
Final aggregation commonly receives near-unique
StringViewgroup keys from partial aggregation. For those inputs, copying every non-inline string into compact buffers adds overhead while providing little compaction benefit.What changes are included in this PR?
GroupValues::mark_near_uniquehook.Utf8Viewgroup keys: after sampling 100,000 rows, mark group values near-unique whengroup_values.len() / sampled_rows > 0.8.StringViewgroup values to retain cloned input buffers in near-unique mode and remap appended views to those buffers.StringViewinterning retains the input data buffer.Are these changes tested?
Yes:
Are there any user-facing changes?
No. This is an internal performance optimization.