You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@doris.apache.org by "foxtail463 (via GitHub)" <gi...@apache.org> on 2026/04/30 11:38:30 UTC

[PR] [refactor](fe) Refactor MV rewrite StructInfo lookup by relation ids [doris]

foxtail463 opened a new pull request, #62981:
URL: https://github.com/apache/doris/pull/62981

### What problem does this PR solve?

Problem Summary:

Nested MV rewrite needs to distinguish two different identities during fuzzy
StructInfo collection:

-- Query starts from base tables and a view over dim_full.
SELECT ...
FROM fact_src t
LEFT JOIN dim_full d0 ...
LEFT JOIN v_dim_full_non_double d1 ...

-- The target MV is defined over child MVs.
SELECT ...
FROM mv_fact t
LEFT JOIN mv_dim_full d0 ...
LEFT JOIN mv_dim_full_view_non_double d1 ...

In this shape, child rewrite can first introduce MV scan relations into memo.
Then the parent group should be able to build a candidate plan from those MV
scan relations and match mv_target.

The old StructInfo candidate path used the table/common-table-id based cache key
in StructInfoMap's candidate map to organize memo candidates. That key only
describes the table family covered by one MV definition; it is a search-space
key, not the identity of a concrete candidate. The exact candidate identity is
relationIdSet, which describes the relations contained by one memo candidate plan
tree.

In the example above, the rewritten scan candidate for mv_dim_full and the
rewritten scan candidate for mv_dim_full_view_non_double can fall into the same
table/common-table-id cache key while representing different relationIdSet
values. If one candidate overwrites or is reused as the other, the parent
mv_target candidate is assembled with the wrong child relation, so the final
target MV rewrite becomes path-sensitive and may fail.

This refactor makes the identity boundary explicit:

- use table ids only to expand the relation search space for an MV
- use exact relationIdSet as the StructInfo candidate identity
- cache candidates by target relation search space, with exact relationIdSet as
the inner key
- register tableId -> relationId when catalog relations enter memo, including
nested MV scan relations
- clear StructInfoMap candidate caches when relation identity changes
- keep candidate plan materialization lazy until StructInfo is actually needed

This keeps base-table, view-derived, and rewritten MV-scan candidates coexisting
under the same coarse table family without overwriting each other.

### Check List (For Author)

- Test 
- [ ] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] 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.
- [ ] No code files have been changed.
- [ ] 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

--
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: commits-unsubscribe@doris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org