Skip to content

Conversation

@zddr
Copy link
Contributor

@zddr zddr commented Jun 4, 2025

pick: #50855

Assuming the SQL definition below, there are two tables (t1, t2) and one
materialized view (mv1).

When determining whether mv1 is synchronized with its base tables, the
system compares:

Whether mvp1 is synchronized with partition p1 and base table t2

Whether mvp2 is synchronized with partition p2 and base table t2

Optimization in this PR:

The original logic would fetch t2's snapshot information twice. This PR
improves efficiency by caching t2's snapshot in the refresh context to
avoid redundant retrieval.

CREATE TABLE t1
(
    k2 TINYINT,
    k3 INT not null
)
PARTITION BY LIST(`k3`)
(
    PARTITION `p1` VALUES IN ('1'),
    PARTITION `p2` VALUES IN ('2')
)

CREATE TABLE t2
(
    k2 TINYINT,
    k3 INT not null
);

create materialized view mv1
partition by(k3)
as
select * from t1 join t2;

mv1 will has two partition mvp1,mvp2
@zddr zddr requested a review from dataroaring as a code owner June 4, 2025 12:01
@Thearas
Copy link
Contributor

Thearas commented Jun 4, 2025

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?

@zddr
Copy link
Contributor Author

zddr commented Jun 4, 2025

run buildall

Copy link
Contributor

@dataroaring dataroaring left a comment

Choose a reason for hiding this comment

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

LGTM

@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Jun 11, 2025
@github-actions
Copy link
Contributor

PR approved by at least one committer and no changes requested.

@github-actions
Copy link
Contributor

PR approved by anyone and no changes requested.

@dataroaring dataroaring merged commit c971c73 into apache:branch-3.0 Jun 12, 2025
22 of 24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants