[fix](hist) Fix unstable result of aggregrate function hist #38608
+193
−15
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
|
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
|
run buildall |
|
clang-tidy review says "All clean, LGTM! 👍" |
1 similar comment
|
clang-tidy review says "All clean, LGTM! 👍" |
|
run buildall |
|
clang-tidy review says "All clean, LGTM! 👍" |
1 similar comment
|
clang-tidy review says "All clean, LGTM! 👍" |
TPC-H: Total hot run time: 42245 ms |
TPC-DS: Total hot run time: 169461 ms |
ClickBench: Total hot run time: 29.8 s |
|
and this change need consider upgrading? |
This pr only has impact on all-null block(in other cases, add method of hist data will be called), and in this situation, the original result could be incorrect, so we only need to avoid crash when we do upgrading. We have two situations here:
In first case, new be will serialize block to a ColumnString, and its max_input_block is -1, old be will do deserialize and merge in its aggregate sink and do get result in its aggregate source. On old be, its merge method actually can not handle the negative max_input_block correctly, and if it happens to be the last block to be merged, we will have trouble ... So it seems we do have upgrading problem in this situation. In the second case, old be will generate a serialized String with max_input_block is 128(default value on old BE), merge method on new be will merge this data, so the result will still be incorrect but it seems no other impact like be crash in this situation. |
|
run buildall |
|
run buildall |
|
clang-tidy review says "All clean, LGTM! 👍" |
TPC-H: Total hot run time: 41742 ms |
TPC-DS: Total hot run time: 170140 ms |
ClickBench: Total hot run time: 29.72 s |
|
run external |
zhangstar333
approved these changes
Aug 5, 2024
github-actions
bot
added
the
approved
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
zhiqiang-hhhh
added a commit
to zhiqiang-hhhh/doris
that referenced
this pull request
Aug 5, 2024
…8608) * Target Fix unstable result of hist function when involving null value. * Reproduce test result of `regression-test/suites/query_p0/sql_functions/aggregate_functions/test_aggregate_all_functions2.groovy` is unstable, sql `SELECT histogram(k7, 5) FROM baseall` will sometimes acts like the second argument is not passed in. * Root reason We have short-circuit in AggregateFunctionNullVariadicInline, when this row is NULL, the value will not be added by the nested function. Implementation of histogram relies on its add method to get its seconds argument, when we have an all null value block, histogram will not get its seconds arg even if sql is like `select(k7, 5)`, so a max_bucket_num with default value 128 is serialized. When we do merging, and happens to deserialize the above block at last, the max_bucket_num in merge stage will be assigned to 128, and this leads to the wrong result. * Fix by Init value of max_bucket_num is assigned to 0, when we do merging, we will discard this aggregated data if its max_bucket_num is 0.
zhiqiang-hhhh
added a commit
to zhiqiang-hhhh/doris
that referenced
this pull request
Aug 5, 2024
…8608) * Target Fix unstable result of hist function when involving null value. * Reproduce test result of `regression-test/suites/query_p0/sql_functions/aggregate_functions/test_aggregate_all_functions2.groovy` is unstable, sql `SELECT histogram(k7, 5) FROM baseall` will sometimes acts like the second argument is not passed in. * Root reason We have short-circuit in AggregateFunctionNullVariadicInline, when this row is NULL, the value will not be added by the nested function. Implementation of histogram relies on its add method to get its seconds argument, when we have an all null value block, histogram will not get its seconds arg even if sql is like `select(k7, 5)`, so a max_bucket_num with default value 128 is serialized. When we do merging, and happens to deserialize the above block at last, the max_bucket_num in merge stage will be assigned to 128, and this leads to the wrong result. * Fix by Init value of max_bucket_num is assigned to 0, when we do merging, we will discard this aggregated data if its max_bucket_num is 0.
dataroaring
pushed a commit
that referenced
this pull request
Aug 5, 2024
* Target Fix unstable result of hist function when involving null value. * Reproduce test result of `regression-test/suites/query_p0/sql_functions/aggregate_functions/test_aggregate_all_functions2.groovy` is unstable, sql `SELECT histogram(k7, 5) FROM baseall` will sometimes acts like the second argument is not passed in. * Root reason We have short-circuit in AggregateFunctionNullVariadicInline, when this row is NULL, the value will not be added by the nested function. Implementation of histogram relies on its add method to get its seconds argument, when we have an all null value block, histogram will not get its seconds arg even if sql is like `select(k7, 5)`, so a max_bucket_num with default value 128 is serialized. When we do merging, and happens to deserialize the above block at last, the max_bucket_num in merge stage will be assigned to 128, and this leads to the wrong result. * Fix by Init value of max_bucket_num is assigned to 0, when we do merging, we will discard this aggregated data if its max_bucket_num is 0.
yiguolei
pushed a commit
that referenced
this pull request
Aug 6, 2024
yiguolei
pushed a commit
that referenced
this pull request
Sep 11, 2024
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.
Fix unstable result of hist function when involving null value.
test result of
regression-test/suites/query_p0/sql_functions/aggregate_functions/test_aggregate_all_functions2.groovyis unstable, sqlSELECT histogram(k7, 5) FROM baseallwill sometimes acts like the second argument is not passed in.We have short-circuit in AggregateFunctionNullVariadicInline, when this row is NULL, the value will not be added by the nested function. Implementation of histogram relies on its add method to get its seconds argument, when we have an all null value block, histogram will not get its seconds arg even if sql is like
select(k7, 5), so a max_bucket_num with default value 128 is serialized. When we do merging, and happens to deserialize the above block at last, the max_bucket_num in merge stage will be assigned to 128, and this leads to the wrong result.Init value of max_bucket_num is assigned to 0, when we do merging, we will discard this aggregated data if its max_bucket_num is 0.