alamb commented on a change in pull request #9882:
URL: https://github.com/apache/arrow/pull/9882#discussion_r607753826
##########
File path: rust/datafusion/src/physical_plan/planner.rs
##########
@@ -344,13 +345,33 @@ impl DefaultPhysicalPlanner {
JoinType::Left => hash_utils::JoinType::Left,
JoinType::Right => hash_utils::JoinType::Right,
};
-
- Ok(Arc::new(HashJoinExec::try_new(
- left,
- right,
- &keys,
- &physical_join_type,
- )?))
+ if ctx_state.config.concurrency > 1 {
+ let left_expr = keys.iter().map(|x| col(&x.0)).collect();
+ let right_expr = keys.iter().map(|x| col(&x.1)).collect();
+
+ // Use hash partition by defualt to parallelize hash joins
+ Ok(Arc::new(HashJoinExec::try_new(
+ Arc::new(RepartitionExec::try_new(
Review comment:
> we might also try to reduce the n.r. of knobs we add?
Yeah, lots of knobs isn't ideal... but sometimes they are helpful as an
escape hatch / workaround if someone hits an error.
> We have to have a solution for that at some point to buffer only up to x
batches or x MB something like that.
I think the challenge when using hash partitioning, in the pathological case
you actually *do* have to buffer all the input
For example,if one input to the hash was all NULLs and the other side had
10M non-null values and then a NULL. You effectively will end up with all the
NULLs in a single partition that can't make any progress until the other side
has been completely drained.
The best you can do I think is to make sure your repartitioning algorithm
responds to backpressure but also is prepared to buffer / spill the entire
thing to disk
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
