Skip to content

branch-3.1: [fix](compaction) Avoid repeatedly compacting large cumulative rowset #64954 #65470 - #67600

Open
Yukang-Lian wants to merge 2 commits into
apache:branch-3.1from
Yukang-Lian:codex/pick-64954-doris-3.1-20260907
Open

branch-3.1: [fix](compaction) Avoid repeatedly compacting large cumulative rowset #64954 #65470#67600
Yukang-Lian wants to merge 2 commits into
apache:branch-3.1from
Yukang-Lian:codex/pick-64954-doris-3.1-20260907

Conversation

@Yukang-Lian

Copy link
Copy Markdown
Collaborator

What problem does this PR solve?

Issue Number: None

Related PR: #64954, #65470

Problem Summary: Backport the cumulative-compaction large-head fix from #64954 to branch-3.1, together with the final mergeable-input protection from #65470.

#64954 removes the promotion-size early return so level-size trimming can exclude an oversized leading rowset instead of repeatedly compacting it. It also keeps the last suffix rowset available for the singleton checks. The same behavior is applied to the cloud and local size-based policies.

branch-3.1 predates the deferred max-score tail-trimming mechanism changed by #65470, so that later implementation cannot be cherry-picked directly. This backport preserves #65470's final invariant in the branch's collection-time guard: trimming must not strand a single non-overlapping rowset when its direct successor is needed to form a mergeable input. Focused cloud and local regression cases cover both the stranded-head and overlapping-singleton max-score scenarios.

The source commits are a1e076e8d6969feafd8411f7b19e22664f43c543 (#64954) and 54300f922fddbeac6e679a83d7829444d4a72f77 (#65470). The branch is based on the latest branch-3.1 at publication time.

Release note

Avoid repeatedly compacting an oversized cumulative rowset while keeping trimmed inputs mergeable on branch-3.1.

Check List (For Author)

  • Test: Regression coverage added for both cloud and local cumulative-compaction policies
    • Clang Format 16 changed-line check: passed
    • git diff --check: passed
    • Full branch-specific BE unit tests were not run locally; hosted CI is requested below
  • Behavior changed: Yes
    • Allows level-size trimming to exclude an oversized leading rowset
    • Preserves a mergeable successor for singleton inputs
  • Does this need documentation: No

…apache#64954)

- Remove the promotion-size early return in size-based cumulative
compaction rowset selection so level-size trimming can exclude an
oversized leading rowset.
- Keep the level-size trimming loop from trimming a single candidate
rowset to an empty input set.
- Apply the same behavior to both cloud and storage cumulative
compaction policies.
- Add regression coverage for the large-head/small-tail case and the
single-rowset guard in both paths.

(cherry picked from commit a1e076e)
…ng (apache#65470)

Issue Number: None

Related PR: apache#59268

Problem Summary:

When the cumulative compaction max score is reduced, back trimming can
leave a single non-overlapping rowset. It cannot be compacted alone, so
compaction repeatedly returns `CUMULATIVE_NO_SUITABLE_VERSION` without
advancing the cumulative point.

This change remembers the last trimmed rowset in both cloud and local
size-based policies. If trimming strands a single non-overlapping
rowset, it restores the direct successor and allows one max-score
overshoot so the input remains mergeable. Existing overlapping-singleton
and cloud empty-rowset behavior is unchanged.

Prevent max-score trimming from leaving an unmergeable cumulative
compaction input.

(cherry picked from commit 54300f9)
@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?

@Yukang-Lian

Copy link
Copy Markdown
Collaborator Author

run buildall

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