-
Notifications
You must be signed in to change notification settings - Fork 103
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
Hash join flatten fix #4668
Hash join flatten fix #4668
Conversation
Benchmark ResultMaster commit hash:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4668 +/- ##
=======================================
Coverage 86.60% 86.60%
=======================================
Files 1373 1373
Lines 58273 58267 -6
Branches 7231 7226 -5
=======================================
- Hits 50465 50460 -5
+ Misses 7642 7641 -1
Partials 166 166 ☔ View full report in Codecov by Sentry. |
@@ -165,6 +165,24 @@ binder::expression_vector LogicalHashJoin::getJoinNodeIDs( | |||
return result; | |||
} | |||
|
|||
class JoinNodeIDUniquenessAnalyzer { | |||
public: | |||
bool isUnique(LogicalOperator* op, const binder::Expression& joinNodeID) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not make this function static?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
41c6449
to
7e84af4
Compare
Benchmark ResultMaster commit hash:
|
Description
This PR fixes a bug in hash join planning exposed in PR #4625. Below is a description of the bug.
We append flatten to probe side if and only if join key is an internal ID and this ID is guaranteed to be unique on the build side. The check was done based on number of factorization group. This is not true if an aggregation happens, which will always reduce the number of factorization group to 1.
This PR checks by looking at operators along the build side subplan.
Testing
The bug cannot be revealed easily on master because we don't reorder multi-part queries. So aggregation does not happen on build side. I have tested by cherry-picking to #4625.
Fixes # (issue)
Contributor agreement