Uh oh!
There was an error while loading. Please reload this page.
[fix](fe) Preserve narrowing datetimev2 casts in simplify in predicate - #63343
Conversation
starocean999
commented
May 18, 2026
/review |
hello-stephen
commented
May 18, 2026
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
There was a problem hiding this comment.
Review result: no blocking issues found.
Critical checkpoint conclusions:
- Goal and proof: The PR fixes
SimplifyInPredicateso it no longer removes semantics-changing narrowingDATETIMEV2casts, and fixes decimal-scale literal alignment. The added unit/regression cases cover the intended behavior, including the result-preserving narrowing-cast case. - Scope and clarity: The implementation is small and focused on the existing rewrite rule.
- Concurrency/lifecycle/config/compatibility: Not applicable; this is a local FE expression rewrite and test change, with no new shared state, lifecycle management, config, storage format, or wire protocol changes.
- Parallel paths: The modified path is the existing
IN-predicate simplification path; date/datev2 behavior is unchanged, and the datetimev2 path now preserves narrowing casts. - Conditions: The new scale guard is the right semantic condition for avoiding narrowing cast removal, and the literal alignment check now uses decimal scale factors rather than binary factors.
- Test coverage: Unit tests and an ordered regression test were added. I did not run the tests in this review environment.
- Observability/transactions/data writes: Not applicable.
- Performance: No meaningful regression identified; the added checks are constant/simple per literal and remain within the existing rewrite logic.
- User focus points: No additional user-provided review focus was present.
Minor note: git diff --check reports a blank line at EOF in the new .out file, but this is not a correctness blocker.
starocean999
commented
May 18, 2026
run buildall |
hello-stephen
commented
May 18, 2026
FE UT Coverage ReportIncrement line coverage |
hello-stephen
commented
May 18, 2026
TPC-H: Total hot run time: 31526 ms |
hello-stephen
commented
May 18, 2026
TPC-DS: Total hot run time: 169594 ms |
hello-stephen
commented
May 19, 2026
FE Regression Coverage ReportIncrement line coverage |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
Uh oh!
There was an error while loading. Please reload this page.
#63343) ### What problem does this PR solve? SimplifyInPredicate could incorrectly remove narrowing DATETIMEV2 casts inside IN predicates. For expressions such as `CAST(datetimev2(6) AS DATETIMEV2(3)) IN (...)`, the rewrite could turn the predicate into a direct comparison on the original DATETIMEV2(6) column, which is not semantics-preserving because the cast uses precision reduction and rounding. The rule also used a binary-based microsecond alignment check instead of a decimal scale check, which could incorrectly treat some literals as losslessly convertible. This change restricts the rewrite to non-narrowing DATETIMEV2 casts and fixes the literal alignment check to use decimal scale factors. It also adds FE unit tests and a regression case for the reported DATETIMEV2 scenario.
#63343) ### What problem does this PR solve? SimplifyInPredicate could incorrectly remove narrowing DATETIMEV2 casts inside IN predicates. For expressions such as `CAST(datetimev2(6) AS DATETIMEV2(3)) IN (...)`, the rewrite could turn the predicate into a direct comparison on the original DATETIMEV2(6) column, which is not semantics-preserving because the cast uses precision reduction and rounding. The rule also used a binary-based microsecond alignment check instead of a decimal scale check, which could incorrectly treat some literals as losslessly convertible. This change restricts the rewrite to non-narrowing DATETIMEV2 casts and fixes the literal alignment check to use decimal scale factors. It also adds FE unit tests and a regression case for the reported DATETIMEV2 scenario.
apache#63343) ### What problem does this PR solve? SimplifyInPredicate could incorrectly remove narrowing DATETIMEV2 casts inside IN predicates. For expressions such as `CAST(datetimev2(6) AS DATETIMEV2(3)) IN (...)`, the rewrite could turn the predicate into a direct comparison on the original DATETIMEV2(6) column, which is not semantics-preserving because the cast uses precision reduction and rounding. The rule also used a binary-based microsecond alignment check instead of a decimal scale check, which could incorrectly treat some literals as losslessly convertible. This change restricts the rewrite to non-narrowing DATETIMEV2 casts and fixes the literal alignment check to use decimal scale factors. It also adds FE unit tests and a regression case for the reported DATETIMEV2 scenario.
What problem does this PR solve?
SimplifyInPredicate could incorrectly remove narrowing DATETIMEV2 casts inside IN predicates.
For expressions such as
CAST(datetimev2(6) AS DATETIMEV2(3)) IN (...), the rewrite could turn the predicateinto a direct comparison on the original DATETIMEV2(6) column, which is not semantics-preserving because the cast
uses precision reduction and rounding. The rule also used a binary-based microsecond alignment check instead of a
decimal scale check, which could incorrectly treat some literals as losslessly convertible.
This change restricts the rewrite to non-narrowing DATETIMEV2 casts and fixes the literal alignment check to use
decimal scale factors. It also adds FE unit tests and a regression case for the reported DATETIMEV2 scenario.
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)