ARROW-11076: [Rust][DataFusion] Refactor usage of right indices in hash join #9048
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Dandandan
changed the title
andygrove
reviewed
Dec 30, 2020
| // Note that we take `.data_ref()` to gather the [ArrayData] of each array. | ||
| let (is_primary, arrays) = match primary[0].schema().index_of(field.name()) { | ||
| Ok(i) => Ok((true, primary.iter().map(|batch| batch.column(i).data_ref().as_ref()).collect::<Vec<_>>())), | ||
| let (is_primary, column_index) = match primary[0].schema().index_of(field.name()) { |
There was a problem hiding this comment.
Another thing we should consider (in a separate PR) is determining upfront which colums are left/rigth and avoid calling schema.index_of for each column in each batch. It is a small cost but we could do it once upfront.
There was a problem hiding this comment.
Yes, agreed, anything we can move out of this inner loop is an improvement, and avoids slowdowns, e.g. with large nr. of columns / smaller batch sizes.
There was a problem hiding this comment.
I think we could in a next PR move the code and pass a column_indices: Vec<usize> instead.
andygrove
approved these changes
Dec 30, 2020
|
For TPC-H q12 at SF=100 and 8 partitions:
Thank you @Dandandan this is superb 💯 |
|
Awesome, better than I expected! |
GeorgeAp
pushed a commit
to sirensolutions/arrow
that referenced
this pull request
Jun 7, 2021
…sh join This applies some refactoring to `build_batch_from_indices` which is supposed to make further changes easier, e.g. solving https://issues.apache.org/jira/browse/ARROW-11030 * This starts handling right (1) batch and left (many) batches differently as for the right batches we can directly use `take` on it. This should be more efficient anyway, and also allows in the future to build the index array directly instead of doing extra copying. * Use `indices.len()` for the capacity parameter, rather than the number of rows at the left. This is of impact at larger sizes (e.g. SF 100), see: apache#9036 Rather than estimating it based on previous batches, this does it based on the (known) number of resulting rows. * Reuse "computed" right indices across multiple columns. * The refactoring makes it easier to apply changes needed for https://issues.apache.org/jira/browse/ARROW-11030 where we need to remove the n*n work that is done for the build side * The changes don't have a big impact locally on performance on TPC-H with small scale factor, but I believe it should have a similar effect as apache#9036 on SF=100 by using `indices.len()` rather than the number of rows in the build side. FYI @jorgecarleitao @andygrove Closes apache#9048 from Dandandan/join_right_refactor Authored-by: Heres, Daniel <danielheres@gmail.com> Signed-off-by: Jorge C. Leitao <jorgecarleitao@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This applies some refactoring to
build_batch_from_indiceswhich is supposed to make further changes easier, e.g. solving https://issues.apache.org/jira/browse/ARROW-11030takeon it. This should be more efficient anyway, and also allows in the future to build the index array directly instead of doing extra copying.indices.len()for the capacity parameter, rather than the number of rows at the left. This is of impact at larger sizes (e.g. SF 100), see: ARROW-11053: [Rust] [DataFusion] Optimize joins with dynamic capacity for output batches #9036 Rather than estimating it based on previous batches, this does it based on the (known) number of resulting rows.indices.len()rather than the number of rows in the build side.FYI @jorgecarleitao @andygrove