Route aggregate index plan breadcrumb values through the match candidate - #4550
Merged
Conversation
hatyo
added
enhancement
hatyo
force-pushed
the
apple/hatyo/aggregate-plan-breadcrumbs
branch
from
September 3, 2026 15:59
744e099 to
d673a3d
Compare
hatyo
marked this pull request as ready for review
September 3, 2026 16:00
hatyo
force-pushed
the
apple/hatyo/aggregate-plan-breadcrumbs
branch
from
September 3, 2026 16:26
d673a3d to
561414f
Compare
alecgrieser
approved these changes
Sep 4, 2026
alecgrieser
left a comment
alecgrieser
left a comment
Collaborator
There was a problem hiding this comment.
LGTM. I think I agree with the approach here regarding backwards (in)compatibility, namely that VC1 is not "current" yet, and so breaking it is fine
normen662
requested changes
Sep 4, 2026
`RecordQueryAggregateIndexPlan` holds a `resultValue` and a `groupByResultValue` that nothing in the plan itself needs: both are breadcrumbs for later planner logic and both are reachable through the plan's match candidate. Neither is read by the plan any more -- `getGroupingValueMaybe()` is gone, and `CardinalitiesProperty`, its only reader anywhere in the repo, derives the grouping value from the `AggregateIndexMatchCandidate` instead. The two fields survive only to keep the `VC0` wire format intact, hence the `todo`s to drop them once the plan hash mode is bumped. Under `PlanHashMode.VC1` the plan hashes and serializes only the result type rather than the whole result value, and `fromProto` rebuilds a `QueriedValue` from it. The group-by result value is not written at all under `VC1`, and deserialization substitutes a `ThrowsValue` so an accidental reader fails loudly instead of quietly seeing the wrong thing. `VL0` and `VC0` keep hashing and writing both values, so existing continuations remain valid. Addresses #3367
hatyo
force-pushed
the
apple/hatyo/aggregate-plan-breadcrumbs
branch
from
September 4, 2026 12:48
561414f to
f604938
Compare
normen662
approved these changes
Sep 4, 2026
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
3 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.
Towards #3367.
RecordQueryAggregateIndexPlanholds aresultValueand agroupByResultValuethat nothing in the plan itself needs — both are breadcrumbs for later planner logic, and both are reachable through the plan's match candidate. Neither is read by the plan any more:getGroupingValueMaybe()is gone, andCardinalitiesProperty, its only reader anywhere in the repo, derives the grouping value from theAggregateIndexMatchCandidateinstead. The two fields survive purely to keep theVC0wire format intact, which is what the remainingtodos track — they come out once the plan hash mode is bumped.Under
PlanHashMode.VC1the plan hashes and serializes only the result type rather than the whole value, andfromProtorebuilds aQueriedValuefrom it; the group-by result value is not written at all, and deserialization substitutes aThrowsValueso that an accidental reader fails loudly rather than quietly seeing the wrong thing.VL0andVC0keep hashing and writing both values, so existing continuations stay valid. Worth a reviewer's eye:VC1is opt-in andCURRENT_FOR_CONTINUATIONis stillVC0, so the default path is untouched, but a deployment already runningVC1would see outstanding aggregate-index continuations fail validation — if the team counts that as user-visible,breaking changeis the better label thanenhancement.