-
Notifications
You must be signed in to change notification settings - Fork 412
Fix decimal floor/ceil (#10365) #10364
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
36aecb4 to
75198fc
Compare
75198fc to
68372fc
Compare
799bf98 to
26fbbb9
Compare
26fbbb9 to
d7aaefc
Compare
dbms/src/Functions/FunctionsRound.h
Outdated
| using Op = IntegerRoundingComputation<NativeType, rounding_mode, ScaleMode::Negative>; | ||
| auto scale_factor = intExp10OfSize<NativeType>(decimal_scale); | ||
|
|
||
| if constexpr (std::is_same_v<T, OutputType>) |
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 which case will the output be Int64, and in which case will the output type the same as T?
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.
For decimal(M, N), if M-N > 18, use T; otherwise use Int64. Because Int64 is sufficient to represent 18-digit integers. TiDB will make decision.
dbms/src/Functions/FunctionsRound.h
Outdated
|
|
||
| if constexpr (std::is_same_v<T, OutputType>) | ||
| { | ||
| Op::compute(&in->value, scale_factor, &out->value); |
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 the output type is decimal, will the return type of ceil/floor keep its input type's scale, or the result type's scale is always 0?
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.
will keep its input type's scale.
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.
Are you sure of this? Because from TiDB's code, it seems if the return type is decimal, the scale is always 0:
https://github.com/pingcap/tidb/blob/ad52c8e05b49602888f08db4a81cfcffbb21e555/pkg/expression/builtin_math.go#L732-L735
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.
From getReturnTypeImpl of FunctionRounding class, we can see that return type is just arguments[0], and I didn't change that in this pr. Maybe some other places change the scale to 0 after. Let me try to find out.
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.
that is because after TiFlash's function, we will add extra cast to keep the return type the same as TiDB. But for this particular function, I think we can adopt TiDB's return type infer logic in TiFlash so we don't need to add extra cast after the function.
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.
OK, I will optimize that.
bf4b947 to
fb9278c
Compare
dbms/src/Functions/FunctionsRound.h
Outdated
| // So, we only handle ScaleMode::Zero here. | ||
| if constexpr (scale_mode == ScaleMode::Zero) | ||
| { | ||
| auto scale_factor = intExp10OfSize<NativeType>(decimal_scale); |
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.
why not use scale_factor as the last parameter of compute, so we don't need calcuate scale_factor for every input row
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.
Good suggestion, I will refactor this part.
Originally, I didn’t want to make major change, like modifying function interface.
fb9278c to
ef767b0
Compare
|
/retest |
windtalker
left a comment
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.
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: windtalker, wshwsh12 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[LGTM Timeline notifier]Timeline:
|
|
In response to a cherrypick label: new pull request created to branch |
|
In response to a cherrypick label: new pull request created to branch |
|
In response to a cherrypick label: new pull request created to branch |
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
|
In response to a cherrypick label: new pull request created to branch |
What problem does this PR solve?
Issue Number: close #10365, close #3496, ref pingcap/tidb#63086
Problem Summary:
What is changed and how it works?
Check List
Tests
Side effects
Documentation
Release note