[fix](expr opt) Preserve division denominator boundaries - #67892
Open
morrySnow wants to merge 1 commit into
Open
[fix](expr opt) Preserve division denominator boundaries#67892morrySnow wants to merge 1 commit into
morrySnow wants to merge 1 commit into
Conversation
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: SimplifyArithmeticRule flattened multiplication and division across a nested denominator. For example, it rewrote 1 / (1 / number) to number * 1, changing the result for zero from NULL to 0. This reassociation can also change null, overflow, and floating-point behavior.
Treat a subtree reached in denominator position during multiply/divide flattening as an atomic operand. The regular recursive rewrite can still simplify inside that subtree, but its factors cannot cross the enclosing division boundary. Unit and regression tests cover nested division and multiplication denominators, zero and nullable values, and integer, double, and decimal expressions.
### Release note
Fix incorrect query results when arithmetic simplification reassociates expressions across nested division denominators.
### Check List (For Author)
- Test: Unit Test and Regression test
- ./run-fe-ut.sh --run org.apache.doris.nereids.rules.expression.SimplifyArithmeticRuleTest
- ./run-regression-test.sh --conf /tmp/env2-range-regression-conf.groovy --run -f regression-test/suites/nereids_rules_p0/expression/simplify_arithmetic/test_simplify_arithmetic.groovy
- DISABLE_BUILD_UI=ON ./build.sh --fe
- Behavior changed: Yes. Nested denominator expressions remain evaluation boundaries, preserving zero, null, overflow, and floating-point semantics.
- Does this need documentation: No
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
8 tasks
Contributor
FE UT Coverage ReportIncrement line coverage |
morrySnow
changed the title
Contributor
TPC-H: Total hot run time: 16768 ms |
Contributor
TPC-DS: Total hot run time: 82062 ms |
Contributor
ClickBench: Total hot run time: 14.64 s |
hello-stephen
pushed a commit
that referenced
this pull request
Sep 12, 2026
…67897) Since today every `Doris_DorisCloudRegression_VaultP0` run dies in the `run` step before executing a single test, e.g. #67883 (TeamCity build 39010) and #67881 / #67882 / #67885 / #67886 / #67892 / #67893: ``` doris-external--minio Pulling doris-external--minio Error Error response from daemon: pull access denied for minio/minio, repository does not exist or may require 'docker login': denied: requested access to the resource is denied ERROR: start minio docker twice failed ``` MinIO stopped publishing container images in October 2025 (the project is a source-only distribution now, see minio/minio#21647) and the `minio/minio` and `minio/mc` repositories have since been removed from Docker Hub altogether (`https://hub.docker.com/v2/repositories/minio/minio/` answers 404, same for `minio/mc`). The few VaultP0 runs that still pass do so only on agents that have the image cached locally (their logs have no `Pulling` line). The iceberg, hudi and polaris third-party fixtures, `test_file_cache_warmup_read_metrics_docker` (which runs a `docker run minio/minio` itself), the all-in-one `cloud.yml` and the datalake samples reference the same images and are one cache eviction away from the same failure. `quay.io/minio/minio` and `quay.io/minio/mc` still serve every tag we use -- `RELEASE.2024-11-07T00-52-20Z`, `RELEASE.2025-01-20T14-49-07Z`, mc `RELEASE.2025-01-17T23-25-50Z`, the two 2022 tags of the samples and `latest` -- and MinIO keeps pushing hotfix tags there (latest one dated 2026-04). `docker manifest inspect` resolves all of them (amd64 / arm64 / ppc64le). So every reference gets the `quay.io/` prefix and the tags stay exactly as they were: same builds, different registry. The CI agents already pull from quay.io for the OceanBase fixture. A longer-term option is to mirror these three tags into the project's own `doristhirdpartydocker` namespace, which already hosts hive / zookeeper / kafka / trinodb; that needs someone with push access to that Docker Hub organization and can follow separately.
starocean999
approved these changes
Sep 12, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Problem
Arithmetic simplification could change query results by moving factors across a nested division denominator. In particular, zero and nullable inputs could produce a non-NULL value after rewriting.
Root cause
The multiply/divide flattening traversal propagated the outer denominator polarity into the denominator subtree. It then inverted or moved the subtree multiplication and division operands into the enclosing expression, even though a denominator is an evaluation boundary.
Reproduction
1 / (1 / number) was rewritten to number * 1. For number = 0, the original expression evaluates to NULL while the rewritten expression evaluates to 0. The same unsafe flattening affected shapes such as x / (y / z) and x / (y * z).
Fix
Keep every complete subtree reached in denominator position as an atomic operand during multiply/divide flattening. The normal recursive rewrite still simplifies within that subtree, but no factor can be inverted or moved across its enclosing division boundary. Add focused unit coverage for integer, nullable, double, decimal, and zero cases, plus end-to-end plan and result checks.
Tests