Skip to content

[fix](regression) Stabilize sync MV selection in MTMV test#65485

Draft
shuke987 wants to merge 1 commit into
apache:masterfrom
shuke987:agent/stabilize-create-mv-and-mtmv-use-mv
Draft

[fix](regression) Stabilize sync MV selection in MTMV test#65485
shuke987 wants to merge 1 commit into
apache:masterfrom
shuke987:agent/stabilize-create-mv-and-mtmv-use-mv

Conversation

@shuke987

@shuke987 shuke987 commented Jul 12, 2026

Copy link
Copy Markdown
Collaborator

What problem does this PR solve?

Issue Number: None

Related PR: #37396

Problem Summary:

test_create_mv_and_mtmv verifies that an async MTMV can read a sync rollup MV, resolve the rollup column back to the base-table partition column, and complete full and partial refreshes.

The original case disabled cost-based sync MV selection so both the precondition query and MTMV definition actually read the sync rollup. After that control was removed, TRY_IN_RBO could successfully generate the rollup candidate while cost-based planning still selected the base index, causing an intermittent MaterializedViewRewriteSuccessButNotChose failure before MTMV creation.

Add USE_MV to both queries so the case deterministically exercises the intended sync-rollup path while retaining the existing full and partial refresh assertions.

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
      • Parsed the modified Groovy suite with GroovyShell.
      • Ran git diff --check.
    • 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.
      • 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?

Issue Number: close #xxx

Related PR: apache#37396

Problem Summary: The test verifies that an async MTMV can read a sync rollup and resolve its partition column back to the base table. After the old non-cost-based sync MV control was removed, TRY_IN_RBO could successfully generate the rollup candidate while cost-based planning still selected the base index. Add USE_MV to both the precondition query and the MTMV definition so the test deterministically exercises the intended sync-rollup path.

### Release note

None

### Check List (For Author)

- Test: Groovy parse and git diff --check
    - Regression test syntax validation
- Behavior changed: No
- Does this need documentation: No
@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?

@shuke987

Copy link
Copy Markdown
Collaborator Author

run buildall

@shuke987

Copy link
Copy Markdown
Collaborator Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review summary for PR #65485:

I reviewed the single-file regression change in regression-test/suites/rollup_p0/test_create_mv_and_mtmv.groovy against the live GitHub patch and relevant FE paths for USE_MV, sync rollup selection, MTMV create analysis, stored query SQL, and MTMV refresh planning. I did not find a substantiated issue that needs an inline review comment.

Critical checkpoint conclusions:

  • Goal/test intent: The change keeps the existing MTMV full and partial refresh assertions while forcing the precondition query and stored MTMV query through the intended sync rollup path.
  • Scope: The patch is small and focused: one explanatory comment, two USE_MV hints, and EOF newline cleanup.
  • Parallel paths: The hint is present both in the precondition explain query and in the MTMV definition. The refresh path reparses mtmv.getQuerySql() through UpdateMvByPartitionCommand.from, so the stored hint is available for later refresh planning.
  • Session/config compatibility: Existing pre_materialized_view_rewrite_strategy = TRY_IN_RBO remains, and MTMV context creation restores saved result-affecting session variables for refresh.
  • Test output determinism: Existing qt_ checks order by dt, advertiser; the expected output in regression-test/data/rollup_p0/test_create_mv_and_mtmv.out remains consistent because result rows do not change.
  • Concurrency/lifecycle/persistence: No new concurrency, lifecycle, persistence format, FE-BE protocol, or configuration item is introduced.
  • Validation limits: This runner is a shallow/grafted checkout with missing .worktree_initialized, missing thirdparty/installed, and no groovy command, so I did not run the full regression suite. I verified the live PR patch scope, existing review-comment state, expected output, and added-line whitespace statically.

User focus: No additional user-provided review focus was present.

Subagent conclusions: The optimizer-rewrite and tests-session-config subagents both completed the initial pass with no candidates. The main review dismissed one suspected duplicate-hint-state interaction with code evidence. Convergence round 1 ended with both live subagents replying NO_NEW_VALUABLE_FINDINGS for the same ledger and empty proposed final comment set.

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