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
compute: sort snapshot arrangements once instead of merging them
While a dataflow hydrates, every update reaching an arrangement carries the
snapshot time. The merge batcher still sorts each 64 KiB chunk and folds it
into a geometric ladder of two-way merges, copying every row once per level
(about thirteen times at 10M rows) and comparing full rows at every step,
although nothing can cancel across times and the sealed chain is simply
every update in `(data, time)` order, consolidated.
`SnapshotBatcher` holds incoming chunks untouched while they all share one
time. At `seal` it sorts a compact `(key prefix, chunk, position)` index,
comparing full rows only on equal prefixes, and emits the sorted and
consolidated chain in one copy pass. The first chunk with a second time hands
everything held to a `MergeBatcher` and the batcher stays on that path, so
steady-state behaviour is unchanged. `RowRef::sort_prefix` provides the
prefix next to the `Ord` impl whose order it must agree with.
Row-keyed arrangement sites use it through the `RowRowBatcher`,
`RowValBatcher` and `RowBatcher` aliases and the two direct
`Col2ValBatcher` sites in `context.rs` and `linear_join.rs`.
Measured on one worker at 10M rows, five repetitions each, against the
same tree without this change: a plain index on a table 3.53s to 2.81s
(the arrangement operator 2.00s to 1.27s), an index on a distinct view
5.40s to 4.76s (2.25s to 1.68s), a fact-to-dimension join 8.3 to 11.5s
down to 7.25s (input arrangement 2.0s to 1.6s, output 1.7s to 1.1s), and a
count-by-key aggregate 7.36s to 6.96s.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
0 commit comments