You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or 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
This code removes the assumption that the unsorted array's size and the sorted array's size is always the same or less (as discussed in #3747). Now we always do a final check on whether there is any size mismatch, and if we find one we record it so that the next iterations can decide whether to spill or not in a more reliable fashion.
What changes are included in this PR?
Fixes the broken check that assumes size(sorted_arr) <= size(input_arr). We also now record the changes in size no matter whether there is a propagated limit or not, since the size might actually be different without any change in the underlying data.
Are there any user-facing changes?
This is a fix/correction of two problems, the first one is the wrong check mentioned in #3747 and the second one is the wrong calculation of in-memory sorted arrays where the final result actually takes more space than we initially assumed it would.
Benchmark runs are scheduled for baseline = d863853 and contender = 0ab0e0f. 0ab0e0f is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java
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.
Which issue does this PR close?
Closes #3747.
Rationale for this change
This code removes the assumption that the unsorted array's size and the sorted array's size is always the same or less (as discussed in #3747). Now we always do a final check on whether there is any size mismatch, and if we find one we record it so that the next iterations can decide whether to spill or not in a more reliable fashion.
What changes are included in this PR?
Fixes the broken check that assumes
size(sorted_arr) <= size(input_arr). We also now record the changes in size no matter whether there is a propagated limit or not, since thesizemight actually be different without any change in the underlying data.Are there any user-facing changes?
This is a fix/correction of two problems, the first one is the wrong check mentioned in #3747 and the second one is the wrong calculation of in-memory sorted arrays where the final result actually takes more space than we initially assumed it would.