-
Notifications
You must be signed in to change notification settings - Fork 64
Fix hashjoin runtime issue #106
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
Conversation
|
cc @zhejiangxiaomai , |
|
cc @rui-mo |
| } | ||
|
|
||
| // Identify the non-key build side columns and make a decoder for each. | ||
| const auto numDependents = outputType->size() - numKeys; |
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.
In the test case you mentioned, what is the number of numDependents? I guess the reserve function fails only when the reserved value is non-positive, am I correct?
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.
@rui-mo,
If the value < 0, will trigger exception.
terminate called after throwing an instance of 'std::length_error'
what(): vector::reserve
Aborted
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.
I guess a better solution would be to check whether the reserved value is greater than 0. If yes, the reserve functions can be called.
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.
If-Else branch is not better for CPU performance.
And here, reserve will not bring benefit because output schema field is limited.
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.
To reserve before use the vector is a common code style in Velox, and they have gave me some comments on that before. I think we'd better follow that. As for the performance, I think if else would not affect the performance too much here.
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.
Advantages to use reserve: https://www.geeksforgeeks.org/using-stdvectorreserve-whenever-possible/.
|
Maybe we need to discuss this issue with Velox, and use the upstreamed fix. Merge this for now. |
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
relative pr: Fix hashjoin runtime issue oap-project#106 INVALID_STATE on HashJoin when spill is turned on oap-project#154 SIGABRT on DecimalAvgAggregate<UnscaleLongDecimal, UnscaleShortDecimal> when spilling is engaged oap-project#236 Support kPreceeding & kFollowing for window range frame type oap-project#287
* Add doc for arrow backend * README.md
Here, reserve action doesn't bring benefit.
Instead, it will cause issues when outputType->size() < numKeys. Such as: apache/incubator-gluten#790.
So just remove them.