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
{{ message }}
Repository navigation
Decode a deletion vector once across the splits of a DV-backed file in the native Delta scan #5655
Follow-up from the native Delta Lake scan review (#5365). The native scan splits DV-backed files like any other file, and each split already builds its access plan only for the row groups it owns: build_access_plan takes the split's FileRange, skips row groups whose first page starts outside it while keeping file-global row positions, validates the deletion vector against the whole file, and reserves memory only for the selectors the split keeps. The split_access_plan_* tests in delta_dv.rs pin that behavior.
What is left is the deletion vector itself. attach_access_plan runs once per split, and every split of a file fetches the DV blob (or takes the inline payload), checks its CRC, deserializes the whole bitmap and validates its cardinality, even though it only uses the deletions inside its own row groups. A DV-backed file larger than maxSplitBytes repeats that work once per split, and the splits usually run as separate tasks.
Describe the potential solution
Decode a file's deletion vector once and share it across that file's splits, for example through a bounded executor-level cache keyed by the DV descriptor (path, offset and size, or the inline payload) and charged to the memory pool. Start with a split-file benchmark (one large DV-backed file read at several maxPartitionBytes settings) to measure the per-split DV cost before and after, since for a small DV the fetch may already be cheap next to the Parquet read.
Additional context
Raised in the #5365 review discussion. Earlier versions of this issue asked for split-aware access plans, which landed with #5365. #6945 (closes #5656) keeps native-format DV bitmaps compressed while decoding, which lowers each split's decode cost but does not remove the repeated work.
Related candidate patch: dwsmith1983#4 by @ErikBPF replaces the per row deletion walk in build_access_plan with coalesced deletion runs clipped across row group and 32 bit partition boundaries, collapsing fully deleted groups to skips. Single commit on delta_dv.rs, applies cleanly to the current #5365 head, 36 focused tests including a run crossing the partition boundary. It does not enable splitting by itself but is the natural base for split aware preparation; plan is for it to be opened here once #5365 lands.
The problem statement above was wrong: DV-backed files are split today. Rewrote it to say what each split currently does and that the work here is making a split cheaper, not enabling splitting.
changed the title [-]Support splitting large DV-backed files in the native Delta scan[/-][+]Decode a deletion vector once across the splits of a DV-backed file in the native Delta scan[/+]on Oct 28, 2026
Narrowed the scope of this issue, since most of what it asked for is already on main.
When this was filed, every split of a DV-backed file built an access plan for the whole file and reserved memory for all of its selectors. That changed in #5365 before it merged. build_access_plan now takes the split's FileRange, and only the row groups the split owns get selectors:
"Deletion vector marks row {row} but the file only has {group_start} rows"
)));
}
Ok(plan)
}
It keeps file-global row positions across the groups it skips, validates the deletion vector against the whole file, follows DataFusion's half-open dictionary-page boundaries, and reserves memory only for the selectors it keeps. The split_access_plan_* tests cover each of these:
After that, #6945 (closes #5656) stopped native-format decoding from expanding the bitmap row by row, which makes each decode cheaper.
Neither change removes the repeated deletion vector work. attach_access_plan still fetches the blob, checks its CRC, deserializes the full bitmap and validates its cardinality once per split:
Activity
dwsmith1983 commentedon Sep 3, 2026
Related candidate patch: dwsmith1983#4 by @ErikBPF replaces the per row deletion walk in build_access_plan with coalesced deletion runs clipped across row group and 32 bit partition boundaries, collapsing fully deleted groups to skips. Single commit on delta_dv.rs, applies cleanly to the current #5365 head, 36 focused tests including a run crossing the partition boundary. It does not enable splitting by itself but is the natural base for split aware preparation; plan is for it to be opened here once #5365 lands.
dwsmith1983 commentedon Sep 23, 2026
The problem statement above was wrong: DV-backed files are split today. Rewrote it to say what each split currently does and that the work here is making a split cheaper, not enabling splitting.
[-]Support splitting large DV-backed files in the native Delta scan[/-][+]Decode a deletion vector once across the splits of a DV-backed file in the native Delta scan[/+]dwsmith1983 commentedon Oct 28, 2026
Narrowed the scope of this issue, since most of what it asked for is already on main.
When this was filed, every split of a DV-backed file built an access plan for the whole file and reserved memory for all of its selectors. That changed in #5365 before it merged.
build_access_plannow takes the split'sFileRange, and only the row groups the split owns get selectors:datafusion-comet/native/core/src/execution/delta_dv.rs
Lines 163 to 254 in 967d09b
It keeps file-global row positions across the groups it skips, validates the deletion vector against the whole file, follows DataFusion's half-open dictionary-page boundaries, and reserves memory only for the selectors it keeps. The
split_access_plan_*tests cover each of these:datafusion-comet/native/core/src/execution/delta_dv.rs
Lines 1278 to 1523 in 967d09b
After that, #6945 (closes #5656) stopped native-format decoding from expanding the bitmap row by row, which makes each decode cheaper.
Neither change removes the repeated deletion vector work.
attach_access_planstill fetches the blob, checks its CRC, deserializes the full bitmap and validates its cardinality once per split:datafusion-comet/native/core/src/execution/delta_dv.rs
Lines 646 to 678 in 967d09b
So the issue now covers decoding the DV once and sharing it across a file's splits, plus a split-file benchmark to show whether that is worth doing.
dwsmith1983 commentedon Oct 28, 2026
take