[Refactor] Unify position-fallback tabletId-to-bucketSeq fill into one facade helper#76253
Open
xiangguangyxg wants to merge 1 commit into
Open
Conversation
…e facade helper The position-fallback tabletId->bucketSeq fill policy was implemented twice: OlapScanNode.fillTabletId2BucketSeq (early-return form) and inline in PlanFragmentBuilder.visitPhysicalOlapScan (nested if/else form). Two independent producers of the same policy can silently drift. Collapse both into a single static helper RangeColocateScanDispatch.fillTabletId2BucketSeq that writes into a caller-supplied target map, and route both call sites through it. RangeColocateScanDispatch already owns computeBucketSeq and the sibling range-colocate scan helpers, so it is the natural home. This is a behavior-preserving extraction: the helper reproduces both sites exactly for dispatch absent, dispatch present + aligned, and dispatch present + transiently unaligned. Add focused unit tests for the three cases. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: xiangguangyxg <xiangguangyxg@gmail.com>
|
@codex review |
Contributor
Module-risk briefing for Codex reviewThis is review focus, not a finding list. Validate against the diff. High-confidence risks
|
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Contributor
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
Contributor
[FE Incremental Coverage Report]✅ pass : 10 / 10 (100.00%) file detail
|
Contributor
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why I'm doing:
The "position-fallback tabletId→bucketSeq fill policy" — if a
RangeColocateScanDispatchispresent and the scan is range-aligned (
dispatch.computeBucketSeq(selectedIndex) != null), use thatbucketSeq map; otherwise fall back to position-based bucketSeq (
put(allTabletIds.get(i), i)) — waswritten twice:
OlapScanNode.fillTabletId2BucketSeq(private, early-return form), andPlanFragmentBuilder.visitPhysicalOlapScan(nestedif/elseform).Two independent producers of the same policy can silently drift. Today any divergence is benign — the
dispatch-time alignment guard in
OlapScanNode.getBucketNums()fails closed (worst case: one paththrows → shuffle fallback, never a wrong result) — but the duplication is unnecessary and easy to
collapse.
What I'm doing:
Extract the shared policy into a single static facade helper on the class that already owns the
policy's core:
Both call sites now route through it.
RangeColocateScanDispatchis the natural home: it ownscomputeBucketSeqand already hosts the sibling static scan helpers (isTabletRangesAligned,computeAlignedTabletRanges,computeForcedAlignmentBoundaries). The helper appends to thecaller-supplied
targetmap without clearing it, preserving the existing whole-scan accumulationacross sub-partitions.
This is a byte-for-byte behavior-preserving extraction. The two sites were already semantically
identical (early-return vs nested
if/else, same outcomes); the helper reproduces both exactly forall three cases:
dispatch == null(HASH / range non-colocate)dispatch != nullandcomputeBucketSeq != null(aligned)putAll(dispatch map)dispatch != nullandcomputeBucketSeq == null(transiently unaligned)The now-dead private
OlapScanNode.fillTabletId2BucketSeqis removed. No plan shape or bucketSeqassignment changes.
What type of PR is this:
Does this PR entail a change in behavior?
Checklist:
(Added 3 focused unit tests to
RangeColocateScanDispatchTestcovering the three fill cases; theexisting range-colocate plan/dispatch suites —
RangeColocateScanDispatchTest,RangeColocateScanRangeDispatchTest,RangeColocateMixedJoinPlanTest,RangeColocateNullSafeJoinPlanTest— stay green.)Bugfix cherry-pick branch check:
[Refactor]is not auto-backported. The duplication exists on both main and branch-4.1 (therange-colocate feature line), but a pure de-dup needs no backport — recommending main-only; 4.1
parity is optional and left to the maintainer's discretion.