refactor: try reduce aggregate hash index cost on hot path

[dqhl76]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

refactor: try reduce aggregate hash index cost on hot path

When perf tpch-1000 q18, I found find_or_insert on hot path, which cannot be seen on smaller scale dataset.

With pure linear probing (+1 each time), occupied slots tend to cluster. Once you hit such a cluster, the probing process need over a long run of consecutive occupied entries. If, instead, the next probe position is derived from the hash (i.e. more “random”), you break up these clusters. That may well hurt potential SIMD or prefetch optimisations, but it also shortens long probe chains on average.

This idea is insipred by a duckdb's optimization PR. Thanks!

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[github-actions]

Docker Image for PR

• tag: pr-19072-e3377f5-1764931157

note: this image tag is only available for internal use.

[github-actions]

Docker Image for PR

• tag: pr-19072-e3377f5-1764935655

note: this image tag is only available for internal use.

[github-actions]

ClickBench Report

• hits: https://benchmark.databend.com/clickbench/pr/19072/19961084728/hits.html
• tpch100: https://benchmark.databend.com/clickbench/pr/19072/19961084728/tpch100.html
• tpch1000: https://benchmark.databend.com/clickbench/pr/19072/19961084728/tpch1000.html

[forsaken628]

Sequential probing has a greater likelihood of being optimized for SIMD instructions. Or maybe the compiler isn't that smart yet?

[dqhl76]

Sequential probing has a greater likelihood of being optimized for SIMD instructions. Or maybe the compiler isn't that smart yet?

I have saw the improvement from Q18 in tpch 1000 (120.03s -> 111.57s). I will perf for a flame graph to ensure that latter.

Here is my guess:

With pure linear probing (+1 each time), occupied slots tend to cluster. Once you hit such a cluster, the probing process need over a long run of consecutive occupied entries. If, instead, the next probe position is derived from the hash (i.e. more “random”), you break up these clusters. That may well hurt potential SIMD or prefetch optimisations, but it also shortens long probe chains on average.

(BTW, this idea is inspired from an optimisation PR in DuckDB. A related approach from SwissTable is to keep linear probing but increase the step size when you encounter several consecutive occupied slots. I haven’t tested that variant here yet)

[forsaken628]

https://github.com/rust-lang/hashbrown/blob/master/src/raw/mod.rs#L2068

[dqhl76]

https://github.com/rust-lang/hashbrown/blob/master/src/raw/mod.rs#L66-L79

[forsaken628]

Later, we can replace the current Entry with the Group of SwissTable