ARROW-12334: [Rust] [Ballista] Aggregate queries producing incorrect results #10083
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
edrevo
force-pushed
the
fix-shuffle-reads
branch
from
3221b1e
to
547c905
Compare
Codecov Report
@@ Coverage Diff @@
## master #10083 +/- ##
=========================================
Coverage ? 78.90%
=========================================
Files ? 286
Lines ? 64721
Branches ? 0
=========================================
Hits ? 51070
Misses ? 13651
Partials ? 0
Continue to review full report at Codecov.
|
|
Didn't mean to close this, sorry. |
|
@edrevo That assumption is correct. Thanks for tracking this down! |
andygrove
approved these changes
Apr 17, 2021
|
Test failures are related to rust nightly and flatbuffers version. I merged this into master locally and confirmed that tests pass so am going to go ahead and merge. |
GeorgeAp
pushed a commit
to sirensolutions/arrow
that referenced
this pull request
Jun 7, 2021
…results The function that calculated job status from the task status was aggregating all of the partition locations. This is incorrect. Only the partitions of the last stage should be collected. @andygrove, could you confirm that my assumption that the output of any query is contained in the last stage? If there is a possibility of having multiple output stages, then this fix is incorrect. Closes apache#10083 from edrevo/fix-shuffle-reads Authored-by: Ximo Guanter <ximo.guanter@gmail.com> Signed-off-by: Andy Grove <andygrove73@gmail.com>
michalursa
pushed a commit
to michalursa/arrow
that referenced
this pull request
Jun 10, 2021
…results The function that calculated job status from the task status was aggregating all of the partition locations. This is incorrect. Only the partitions of the last stage should be collected. @andygrove, could you confirm that my assumption that the output of any query is contained in the last stage? If there is a possibility of having multiple output stages, then this fix is incorrect. Closes apache#10083 from edrevo/fix-shuffle-reads Authored-by: Ximo Guanter <ximo.guanter@gmail.com> Signed-off-by: Andy Grove <andygrove73@gmail.com>
michalursa
pushed a commit
to michalursa/arrow
that referenced
this pull request
Jun 13, 2021
…results The function that calculated job status from the task status was aggregating all of the partition locations. This is incorrect. Only the partitions of the last stage should be collected. @andygrove, could you confirm that my assumption that the output of any query is contained in the last stage? If there is a possibility of having multiple output stages, then this fix is incorrect. Closes apache#10083 from edrevo/fix-shuffle-reads Authored-by: Ximo Guanter <ximo.guanter@gmail.com> Signed-off-by: Andy Grove <andygrove73@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.
The function that calculated job status from the task status was aggregating all of the partition locations. This is incorrect. Only the partitions of the last stage should be collected.
@andygrove, could you confirm that my assumption that the output of any query is contained in the last stage? If there is a possibility of having multiple output stages, then this fix is incorrect.