You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
timely-util: whole-chunk extract pass-through via resident time bounds (#38254)
### Motivation
A seal walks every stashed chunk to partition updates against the
frontier, and for a spilled chunk that walk previously loaded and
decoded the whole body even when no update in it could possibly be
extracted (or when all of them must be). During sustained ingest the
stash backlog is mostly frontier-disjoint chunks, so per seal this
decoded the entire backlog to move one boundary chunk. The August
benchmark campaign measured the two stash patches together as a 35% mean
and ~2x p90 reduction in co-tenant probe latency at 50cc.
Spilled bodies now carry their time bounds as resident metadata (an
antichain lower bound and the maximal time elements). `extract_into`
uses them for two whole-chunk fast paths: ship the chunk untouched when
the frontier is past all of its times, keep it untouched (folding its
lower bound into the residual frontier) when none of its times are
ready. Only chunks the frontier genuinely straddles are loaded, decoded,
and split.
### Tips for reviewer
* The residual-frontier fold is the subtle part for partial orders: a
kept chunk contributes its lower bound, not its individual times, which
is sound because extraction only needs an upper bound on what remains.
* Both fast paths have dedicated tests, including a frontier-disjoint
pass-through case.
### Checklist
- [ ] This PR has adequate test coverage / QA involvement has been duly
considered. ([trigger-ci for additional test/nightly
runs](https://trigger-ci.dev.materialize.com/))
- [ ] This PR has an associated up-to-date [design
doc](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/README.md),
is a design doc
([template](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/00000000_template.md)),
or is sufficiently small to not require a design.
- [ ] If this PR evolves [an existing `$T ⇔ Proto$T`
mapping](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/command-and-response-binary-encoding.md)
(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](MaterializeInc/cloud#5021)).
- [ ] If this PR includes major [user-facing behavior
changes](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/guide-changes.md#what-changes-require-a-release-note),
I have pinged the relevant PM to schedule a changelog post.
0 commit comments