Skip to content

branch-2.1:[enhance](mtmv)cache table snapshot in refresh context (#50855) #51493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
yiguolei merged 1 commit into from
Jun 5, 2025
Merged

branch-2.1:[enhance](mtmv)cache table snapshot in refresh context (#50855) #51493

yiguolei merged 1 commit into from
Jun 5, 2025

Conversation

@zddr
Copy link
Contributor

@zddr zddr commented Jun 4, 2025

pick: #50855

@zddr
[enhance](mtmv)cache table snapshot in refresh context (apache#50855)
450d2c7 
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 yiguolei as a code owner June 4, 2025 11:56
@hello-stephen
Copy link
Contributor

hello-stephen 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

@yiguolei yiguolei merged commit 831d2c1 into apache:branch-2.1 Jun 5, 2025
20 checks passed
@yiguolei yiguolei mentioned this pull request Aug 11, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@yiguolei yiguolei yiguolei approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@zddr @hello-stephen @yiguolei