Skip to content

Conversation

@LiBinfeng-01
Copy link
Contributor

@LiBinfeng-01 LiBinfeng-01 commented Nov 7, 2024

What problem does this PR solve?

  • Problem
    function like select floor(300.343, 2) precision should be 5 and scale should be 2, but now is (6, 2) after compute precision, but after folding const on fe, it changed to (5, 2) but upper level of plan still expect the output of child to be (6, 2). So it would rise an exception when executing.
  • How it was fixed
    fix folding constant precision of floor/round/ceil/truncate functions from (5, 2) to (6, 2) in upper case
  • Notion
    when second value is negative and it absolute value >= precision - value, it can not be expressed in fe which result is zero with decimal type (3, 0). like 000. So just let it go back and no using folding constant by fe.

Issue Number: close #43421

Related PR: #40744

Problem Summary:

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No colde files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.
  • Release note

    Fix floor/round/ceil functions precision problem

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

@doris-robot
Copy link

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR

Since 2024-03-18, the Document has been moved to doris-website.
See Doris Document.

@LiBinfeng-01
Copy link
Contributor Author

run buildall

morrySnow
morrySnow previously approved these changes Nov 7, 2024
@morrySnow morrySnow added the p0_b label Nov 7, 2024
@github-actions
Copy link
Contributor

github-actions bot commented Nov 7, 2024

PR approved by at least one committer and no changes requested.

@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Nov 7, 2024
@github-actions
Copy link
Contributor

github-actions bot commented Nov 7, 2024

PR approved by anyone and no changes requested.

Comment on lines +418 to +420
testFoldConst("with cte as (select floor(300.343, 2) order by 1 limit 1) select * from cte")
testFoldConst("with cte as (select round(300.343, 2) order by 1 limit 1) select * from cte")
testFoldConst("with cte as (select ceil(300.343, 2) order by 1 limit 1) select * from cte")
Copy link
Contributor

@superdiaodiao superdiaodiao Nov 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested the query before this PR:
with cte as (select truncate(300.343, 2) order by 1 limit 1) select * from cte;,
and the exception is:
ERROR 1105 (HY000): errCode = 2, detailMessage = (9.134.238.135)[INTERNAL_ERROR]output type not match expr type , col name , expected type Decimal(6, 2) , real type Decimal(5, 2).
So whether the truncate() should be tested together?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it make sense, added

@LiBinfeng-01 LiBinfeng-01 changed the title [Fix](Nereids) fix floor/round/ceil functions type compute precision problem [Fix](Nereids) fix floor/round/ceil/truncate functions type compute precision problem Nov 8, 2024
@github-actions github-actions bot removed the approved Indicates a PR has been approved by one committer. label Nov 8, 2024
@LiBinfeng-01
Copy link
Contributor Author

run buildall

1 similar comment
@LiBinfeng-01
Copy link
Contributor Author

run buildall

@LiBinfeng-01
Copy link
Contributor Author

run p0

@LiBinfeng-01
Copy link
Contributor Author

run cloud_p0

@LiBinfeng-01
Copy link
Contributor Author

run buildall

public static Expression truncate(DecimalV3Literal first, IntegerLiteral second) {
if (first.getValue().compareTo(BigDecimal.ZERO) == 0) {
return first;
} else if (first.getValue().compareTo(BigDecimal.ZERO) == -1) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
} else if (first.getValue().compareTo(BigDecimal.ZERO) == -1) {
} else if (first.getValue().compareTo(BigDecimal.ZERO) < 0) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the function compareTo only return 0 -1 and 1, so I think -1 is acceptable for this situation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html
maybe you can check bigDecimal Type implementation for compareTo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed to aligning interface definition

@LiBinfeng-01
Copy link
Contributor Author

run buildall

@LiBinfeng-01
Copy link
Contributor Author

run buildall

@LiBinfeng-01
Copy link
Contributor Author

run buildall

@LiBinfeng-01
Copy link
Contributor Author

run buildall

@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Nov 12, 2024
@github-actions
Copy link
Contributor

PR approved by at least one committer and no changes requested.

@morrySnow morrySnow merged commit 3fffc61 into apache:master Nov 12, 2024
github-actions bot pushed a commit that referenced this pull request Nov 12, 2024
…recision problem (#43422)

- Problem
function like ```select floor(300.343, 2)``` precision should be 5 and
scale should be 2, but now is (6, 2) after compute precision, but after
folding const on fe, it changed to (5, 2) but upper level of plan still
expect the output of child to be (6, 2). So it would rise an exception
when executing.

- How it was fixed 
fix folding constant precision of floor/round/ceil/truncate functions
from (5, 2) to (6, 2) in upper case

- Notion
when second value is negative and it absolute value >= precision -
value, it can not be expressed in fe which result is zero with decimal
type (3, 0). like 000. So just let it go back and no using folding
constant by fe.

- Related PR: #40744

- Release note
    Fix floor/round/ceil functions precision problem in folding constant
github-actions bot pushed a commit that referenced this pull request Nov 12, 2024
…recision problem (#43422)

- Problem
function like ```select floor(300.343, 2)``` precision should be 5 and
scale should be 2, but now is (6, 2) after compute precision, but after
folding const on fe, it changed to (5, 2) but upper level of plan still
expect the output of child to be (6, 2). So it would rise an exception
when executing.

- How it was fixed 
fix folding constant precision of floor/round/ceil/truncate functions
from (5, 2) to (6, 2) in upper case

- Notion
when second value is negative and it absolute value >= precision -
value, it can not be expressed in fe which result is zero with decimal
type (3, 0). like 000. So just let it go back and no using folding
constant by fe.

- Related PR: #40744

- Release note
    Fix floor/round/ceil functions precision problem in folding constant
LiBinfeng-01 pushed a commit to LiBinfeng-01/doris that referenced this pull request Nov 12, 2024
…recision problem (apache#43422)

- Problem
function like ```select floor(300.343, 2)``` precision should be 5 and
scale should be 2, but now is (6, 2) after compute precision, but after
folding const on fe, it changed to (5, 2) but upper level of plan still
expect the output of child to be (6, 2). So it would rise an exception
when executing.

- How it was fixed 
fix folding constant precision of floor/round/ceil/truncate functions
from (5, 2) to (6, 2) in upper case

- Notion
when second value is negative and it absolute value >= precision -
value, it can not be expressed in fe which result is zero with decimal
type (3, 0). like 000. So just let it go back and no using folding
constant by fe.

- Related PR: apache#40744

- Release note
    Fix floor/round/ceil functions precision problem in folding constant
LiBinfeng-01 pushed a commit to LiBinfeng-01/doris that referenced this pull request Nov 12, 2024
…recision problem (apache#43422)

- Problem
function like ```select floor(300.343, 2)``` precision should be 5 and
scale should be 2, but now is (6, 2) after compute precision, but after
folding const on fe, it changed to (5, 2) but upper level of plan still
expect the output of child to be (6, 2). So it would rise an exception
when executing.

- How it was fixed 
fix folding constant precision of floor/round/ceil/truncate functions
from (5, 2) to (6, 2) in upper case

- Notion
when second value is negative and it absolute value >= precision -
value, it can not be expressed in fe which result is zero with decimal
type (3, 0). like 000. So just let it go back and no using folding
constant by fe.

- Related PR: apache#40744

- Release note
    Fix floor/round/ceil functions precision problem in folding constant
py023 pushed a commit to py023/doris that referenced this pull request Nov 13, 2024
…recision problem (apache#43422)

- Problem
function like ```select floor(300.343, 2)``` precision should be 5 and
scale should be 2, but now is (6, 2) after compute precision, but after
folding const on fe, it changed to (5, 2) but upper level of plan still
expect the output of child to be (6, 2). So it would rise an exception
when executing.

- How it was fixed 
fix folding constant precision of floor/round/ceil/truncate functions
from (5, 2) to (6, 2) in upper case

- Notion
when second value is negative and it absolute value >= precision -
value, it can not be expressed in fe which result is zero with decimal
type (3, 0). like 000. So just let it go back and no using folding
constant by fe.

- Related PR: apache#40744

- Release note
    Fix floor/round/ceil functions precision problem in folding constant
yiguolei pushed a commit that referenced this pull request Nov 13, 2024
…pe compute precision problem (#43782)

Cherry-picked from #43422

Co-authored-by: LiBinfeng <libinfeng@selectdb.com>
morrySnow pushed a commit that referenced this pull request Nov 13, 2024
…pe compute precision problem (#43781)

Cherry-picked from #43422

Co-authored-by: LiBinfeng <libinfeng@selectdb.com>
GoGoWen pushed a commit to GoGoWen/incubator-doris that referenced this pull request Sep 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. dev/2.1.8-merged dev/3.0.3-merged p0_b reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] floor function execution failed

7 participants