siddharth234 opened a new issue, #66264: URL: https://github.com/apache/doris/issues/66264
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version doris-4.0.7-rc02 (Cloud Mode). Root-caused to the EliminateGroupByKeyByUniform rule introduced in #43391 (merged to master, backported to branch-3.0/branch-3.1). Not confirmed whether still present on master/latest - repro below should confirm either way. ### What's Wrong? When a query filters an AGGREGATE KEY table on a column via equality (col = 'X'), and that same column is also in the SELECT/GROUP BY list, the EliminateGroupByKeyByUniform rule removes the column from the real GROUP BY at the logical-plan level (since it's provably "uniform" given the predicate) and replaces it with any_value(col) in the output. This happens before materialized-view/rollup rewrite selects a physical scan target. If that later rewrite selects a rollup that does not contain the filtered column at all, the rollup cannot enforce the equality predicate - but nothing re-validates that the "uniform" assumption still holds against the actually-chosen physical plan. The result: the predicate silently disappears from the physical scan's PREDICATES, the aggregate is computed over all rows for the broader group (not just the filtered value), and the originally-requested value is spliced back into the output via any_value/literal substitution - making the wrong, over-aggregated result look like a correctly filtered one, with no error or warning. This is a correctness bug, not a performance issue: values returned can be orders of magnitude larger than the true filtered result, silently. ### What You Expected? Either: 1. The rollup should be rejected as a rewrite candidate for this query (same as it correctly is when the filtered column is not also in the output - see repro below), or 2. If the elimination is kept, the equality predicate must still be enforced against whichever physical target is ultimately chosen, so the aggregate is computed over only the matching rows. ### How to Reproduce? ```sql CREATE TABLE test_db.uniform_rollup_bug ( dt DATE NOT NULL, grp VARCHAR(64) NOT NULL, id VARCHAR(64) NOT NULL, cnt BIGINT SUM NOT NULL ) AGGREGATE KEY(dt, grp, id) PARTITION BY RANGE(dt) () DISTRIBUTED BY HASH(id) BUCKETS 8 PROPERTIES ("replication_num" = "1"); -- Rollup deliberately coarser than the base table: no `id` column. ALTER TABLE test_db.uniform_rollup_bug ADD ROLLUP rollup_dt_grp (dt, grp, cnt); -- wait for rollup build to finish (SHOW ALTER TABLE ROLLUP) INSERT INTO test_db.uniform_rollup_bug VALUES ('2026-01-01', 'g1', 'id1', 5), ('2026-01-01', 'g1', 'id2', 100), ('2026-01-01', 'g1', 'id3', 900); -- (1) BROKEN: id filtered by equality AND selected in output. -- Expected: 5 (id1's own value). Actual: 1005 (sum across the whole group). SELECT dt, id, SUM(cnt) AS cnt FROM test_db.uniform_rollup_bug WHERE grp = 'g1' AND id = 'id1' GROUP BY dt, id; -- (2) CORRECT: identical filter, `id` just removed from the output/GROUP BY. -- This one correctly avoids the rollup and returns the true filtered value. SELECT dt, SUM(cnt) AS cnt FROM test_db.uniform_rollup_bug WHERE grp = 'g1' AND id = 'id1' GROUP BY dt; -- Compare EXPLAIN for both — (1) will show `rollup_dt_grp` chosen with `id` -- absent from both PREDICATES and the physical GROUP BY, and -- MaterializedViewRewriteSuccessAndChose for rollup_dt_grp. -- (2) will show MaterializedViewRewriteFail for the same rollup -- ("View struct info is invalid, Rewrite compensate predicate by view fail"), -- correctly falling back to the base table. EXPLAIN SELECT dt, id, SUM(cnt) FROM test_db.uniform_rollup_bug WHERE grp = 'g1' AND id = 'id1' GROUP BY dt, id; ``` ### Anything Else? - Ruled out stale/corrupted rollup metadata: dropping and rebuilding the rollup with an identical definition reproduces the bug deterministically once the rebuild completes. - Relevant rule: org.apache.doris.nereids.rules.rewrite.EliminateGroupByKeyByUniform (introduced in #43391). ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
