yujun777 commented on PR #68861: URL: https://github.com/apache/doris/pull/68861#issuecomment-6095567305
P0 failures on the previous build (aa37a05d) — diagnosis and what changed since. Three of the reported suites fail because of this change, and all three are the same pattern: a scalar aggregate answered by a grouped MV, asserted with `mv_rewrite_success`, which requires the optimizer to actually pick the MV: - `mv_p0.mv_ignore_predicate.mv_ignore_predicate` — `select count(k2) from d_table` against the mv `kign` - `mv_p0.sum_divede_count.sum_devide_count` — `select sum(k2)/count(k2) from d_table` against the mv `kavg` - `mv_p0.ut.testSelectMVWithTableAlias.testSelectMVWithTableAlias` — `select count(tag_id) from user_tags t` against `user_tags_mv` Before this change those queries were rewritten into the buggy plan — a bare MV scan with the aggregate dropped, which is far cheaper than the base table, so the MV was always chosen. Now the rewrite keeps the aggregate node, and the MV candidate costs about the same as reading the base table, so which side wins depends on the cluster's statistics while the result is the same either way (the `qt_select_mv` goldens in those three suites are unchanged). I switched those three assertions to `mv_rewrite_success_without_check_chosen`, which checks that the mv produced a rewritten candidate without pinning the cbo choice, so the correctness coverage stays and the cost sensitivity goes away. For the new suite `nereids_rules_p0.mv.agg_scalar_empty_input`, it no longer asserts which plan is chosen. It asserts the fix directly on the rewritten candidate in `memo plan` output (`ifnull(sum(` present for the rolled up `count(*)`, and absent for `min`, which is already nullable), keeps the result comparison against `enable_materialized_view_rewrite=false`, and drops the second mv and the `ANALYZE ... WITH SYNC` statements so that it stays light and does not contend with the other MTMV suites in the same directory. `nereids_rules_p0.mv.dimension`, `nereids_rules_p0.mv.negative`, `nereids_rules_p0.mv.agg_with_roll_up` and `nereids_rules_p0.mv.agg_without_roll_up` do not contain a scalar-aggregate-over-grouped-mv `mv_rewrite_success` assertion. On my machine `aggregate_with_roll_up`, `any_value_roll_up` and `aggregate_without_roll_up` pass with this change. `negative` and `dimension` only failed inside `waitingMTMVTaskFinished` with the refresh task left `RUNNING`, and I could reproduce the same hang with `enable_materialized_view_rewrite=false` on a plain single-table `group by`, so that was my local backend rather than this change. -- 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]
