Skip to content

[opt](function) speed up zero-scale decimal casts (#65410)#65576

Merged
Mryange merged 1 commit into
apache:opt_perf_4.1from
Mryange:opt_perf_4.1-dec-cast
Jul 14, 2026
Merged

[opt](function) speed up zero-scale decimal casts (#65410)#65576
Mryange merged 1 commit into
apache:opt_perf_4.1from
Mryange:opt_perf_4.1-dec-cast

Conversation

@Mryange

@Mryange Mryange commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

What problem does this PR solve?

Integer-to-DecimalV3 casts with zero scale previously went through the generic decimal cast path even when the target decimal precision can represent the full integer input range. For example, casting an INT column to DECIMALV3(10, 0) still used the common _from_int helper, which computes decimal scaling and range-related values that are unnecessary when the scale is zero and the cast cannot narrow the integer range.

Root cause: the DecimalV3 cast implementation did not have a direct fast path for non-narrowing integer casts to zero-scale decimal types.

This change adds a direct zero-scale DecimalV3 path for integer and boolean inputs when the target decimal range is not narrower than the input range. The fast path writes the input value directly into the decimal native value and preserves the existing generic path for narrowing casts, non-zero-scale casts, and overflow-sensitive cases.

Local optest profiling for:

select sum(cast(quantity as decimalv3(10,0))) from q14_avg_expr_100m;

showed the cast expression time improving from about 119.0 ms to about 109.7 ms on 100M rows, roughly an 8% reduction in this expression counter.

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

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 code files have been changed.
      • Other reason
  • Behavior changed:

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

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

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

### What problem does this PR solve?

Integer-to-DecimalV3 casts with zero scale previously went through the
generic decimal cast path even when the target decimal precision can
represent the full integer input range. For example, casting an INT
column to DECIMALV3(10, 0) still used the common _from_int helper, which
computes decimal scaling and range-related values that are unnecessary
when the scale is zero and the cast cannot narrow the integer range.

Root cause: the DecimalV3 cast implementation did not have a direct fast
path for non-narrowing integer casts to zero-scale decimal types.

This change adds a direct zero-scale DecimalV3 path for integer and
boolean inputs when the target decimal range is not narrower than the
input range. The fast path writes the input value directly into the
decimal native value and preserves the existing generic path for
narrowing casts, non-zero-scale casts, and overflow-sensitive cases.

Local optest profiling for:

select sum(cast(quantity as decimalv3(10,0))) from q14_avg_expr_100m;

showed the cast expression time improving from about 119.0 ms to about
109.7 ms on 100M rows, roughly an 8% reduction in this expression
counter.
@Mryange
Mryange requested a review from yiguolei as a code owner July 14, 2026 06:46
@hello-stephen

Copy link
Copy Markdown
Contributor

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

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@Mryange
Mryange merged commit da3705c into apache:opt_perf_4.1 Jul 14, 2026
11 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants