-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Remove Eager Trait for Joins #10721
Remove Eager Trait for Joins #10721
Conversation
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.
LGTM, thank you for this simplification.
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.
LGTM as well.
Looks good to me. I don't see that SortMergeJoin is required to use this trait. |
@@ -786,7 +786,7 @@ mod tests { | |||
assert_eq!( | |||
evaluate_partition_prefix( | |||
partitions, | |||
&[col("a").eq(lit("foo")).and((col("b").eq(lit("bar"))))], | |||
&[col("a").eq(lit("foo")).and(col("b").eq(lit("bar")))], |
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.
this already fixed. twice :)
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.
lgtm
* Remove eager trait * Update helpers.rs
Which issue does this PR close?
Closes #.
Rationale for this change
EagerJoinStream
trait is currently implemented only bySymmetricHashJoin
. It was initially designed to be open-ended for other joins that could potentially work with an eager polling strategy. However, this strategy does not provide significant benefits or serve as a better alternative to other strategies. It is specifically suited to the nature ofSymmetricHashJoin
. Therefore, the implementation has been moved directly toSymmetricHashJoin
.Although it was suggested that
SortMergeJoin
might utilize this strategy, it does not require such a polling mechanism.For simplification, this PR removes the redundant trait implementation and moves the existing implementation to where it is actually needed. If this trait is being utilized downstream, please share your thoughts.
What changes are included in this PR?
Removed
EagerJoinStream
and moved its implementation toSymmetricHashJoin
.Removed the
handle_async_state
macro, which does not simplify any complexity.Are these changes tested?
Are there any user-facing changes?
There are no user-facing changes. This PR involves internal refactoring for simplification and does not impact public APIs.