-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the hash join performance by replacing the RawTable to a simple Vec for JoinHashMap #6910
Comments
That's interesting, wonder if you're not getting regressions on other queries (as probing might be slower?) 🤔 At least that's what I got in some earlier experiments. Q17 is also interesting because it fails to plan/estimate the join correctly, it puts the largest side on the build side. |
I think it makes sense to first work on making equality faster, then testing this approach again #12131 |
Current results (closer to mixed results, but more regressions than wins)
|
I am going to experiment with a slight variation on this this weekend to reduce nr of collisions greatly while still using |
Is your feature request related to a problem or challenge?
When testing the TPCH q17 on my PC, based on #6800, it costs around 2.4s. Among them, it costs around 800ms for constructing the
RawTable
ofJoinHashMap
.To only find the hash location, the structure,
RawTable
, we used is too complex and the overhead is too heavy.Describe the solution you'd like
We can simple use a fixed size of vector with a hash mask to look up the hash location.
After applying the replacement, it only cost less than 100ms for the construction of
JoinHashMap
. And the overall time cost for the q17 is reduced from 2.4s to 1.8s.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: