Skip to content

Conversation

@DAlperin
Copy link
Member

In the move to incremental compaction we lost some specificity in the ApplyMergeResult metric since everything is applied via perform_subset_replacement. Instead of unconditionally returning ApplyMergeResult::AppliedSubset we check if the range we are replacing covers the whole batch, and if so return AppliedExact instead. This should return our metric fidelity to their earlier levels.

Motivation

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

In the move to incremental compaction we lost some specificity in the
ApplyMergeResult metric since everything is applied via
`perform_subset_replacement`. Instead of unconditionally returning
`ApplyMergeResult::AppliedSubset` we check if the range we are replacing
covers the whole batch, and if so return `AppliedExact` instead. This
should return our metric fidelity to their earlier levels.
@DAlperin DAlperin requested a review from a team as a code owner November 19, 2025 04:10
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.

1 participant