Skip to content

Aggregate - #219

Merged
cmhulbert merged 10 commits into
developmentfrom
aggregate
Apr 7, 2026
Merged

Aggregate#219
cmhulbert merged 10 commits into
developmentfrom
aggregate

Conversation

@cmhulbert

@cmhulbert cmhulbert commented Mar 26, 2026

Copy link
Copy Markdown
Contributor

This contains code from the previous batching-aggregate branch, but adapted to the changes to development since then. Namely VolatileReadData, and how it is now used.

This changes the default behavior of VolatileReadData.from to return a LazyReadData over an AggregatingSliceTrackingLazyRead. The motivation for this is that the only way to get the aggregation/prefetch behavior would be to manually wrap it in each KVA implementation. It's desirable to be able to do this, but I think it is better to assume reasonable behavior for the default, and allow specialized implementations to handle the optimizations.

Even for FileSystemKVA, we want the aggregating behavior in the default case, since we can not be sure if the files we are reading are actually local (in which case many chunk reads over the same block are maybe fine? I still think probably not ideal), or if they are mounted or remote in some way.

This is especially true since the default behavior for readBlock calls out to readChunksRecursive for all blocks, resulting in individual partial reads for each chunk, rather than materializing the VolatileReadData once up front. The AggregatingSliceTrackingLazyRead handles this.

@cmhulbert
cmhulbert requested review from bogovicj and tpietzsch and removed request for tpietzsch March 26, 2026 20:04
@cmhulbert
cmhulbert force-pushed the aggregate branch 4 times, most recently from b4aef69 to bdf7c57 Compare April 3, 2026 15:54
tpietzsch and others added 10 commits April 3, 2026 21:24
This is in preparation for implementing prefetch() for cloud storage
backends...
…ment

feat: use the aggregate/prefetch logic with VolatileReadData.

By default, `VolatileReadData.from` now uses AggregatingSliceTrackingLazyRead. This is useful to ensure the default VolatileReadData behaves reasonably even for reading many chunks from the same shard.
The wrapped volatileReadData is closed via the wrapper chain
LazyReadData -> AggregatingSliceTrackingLazyRead -> TrackingLazyRead ->
volatileReadData

No need for DelegatingVolatileReadData.
It doesn't do any prefetching, just keeps track of what has been
materialized (and uses that to avoid materializing slices that are
already fully covered).
instead of "...SliceTracking..." which is not their main feature
@cmhulbert
cmhulbert merged commit a3e707b into development Apr 7, 2026
2 checks passed
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.

3 participants