Feature Request / Improvement
Transaction.delete() is copy-on-write: deleting rows rewrites every data file that holds a matched row, so it costs ~O(table) per operation and grows with the table. Add v2 merge-on-read position-delete writes so a delete instead writes a small position-delete file, costing O(rows deleted), with the data files left untouched. v2 position deletes are readable by the existing query engines today, so this is broadly adoptable.
Even as v3 merge-on-read (deletion vectors) support lands, v2 position-delete writes remain valuable, because format version is a per-table property and the two encodings are mutually exclusive: a v2 table can never use a deletion vector. v3 write support therefore does nothing for the large existing v2 fleet, whose tables stay v2 until deliberately upgraded and often must stay v2 to remain readable by every engine that consumes them (v3 deletion vectors require newer readers). For those tables, position deletes are the only efficient delete path, and they are also the format Java/Spark Iceberg already writes, so this also closes a read/write asymmetry in PyIceberg. Deletion vectors are the right default for new v3 tables; v2 position deletes serve the installed base.
What already exists (no work needed)
- The read path already applies position deletes at scan time (the delete-file index / position-delete application).
POSITIONAL_DELETE_SCHEMA (file_path, pos), DataFileContent.POSITION_DELETES, ManifestContent.DELETES, and the full snapshot / manifest-list / commit machinery.Transaction.delete() already recognizes write.delete.mode=merge-on-read. It currently just warns "not yet supported" and falls back to copy-on-write. That fallback is the hook point.
The gap to close
- Widen
pos in POSITIONAL_DELETE_SCHEMA from int to long. The Iceberg spec types pos as long; keeping it int mismatches what other engines write/read and overflows on files with more than 2^31 rows. The read path treats pos as a generic index, so widening is safe.
- A DELETES manifest writer. The v2 manifest writer hardcodes manifest content to
data; a variant is needed that writes content deletes.
- A snapshot producer that adds position-delete files (writes a DELETES manifest for them, grouped by partition spec, and carries existing manifests forward), committing an overwrite snapshot.
- A position-delete file writer that records exact
file_path lower/upper bounds. The read-side delete-file index pins a delete to a single data file only when its file_path bound is exact; the default truncate(16) write-metrics mode would truncate that bound and mis-route (or over-apply) the delete.
- Predicate to positions resolution. For each data file a delete predicate touches, read it in physical order and collect the ordinal row positions that match, then write one position-delete file per touched data file.
- Wire 1 through 5 into the merge-on-read branch of
Transaction.delete(), gated behind write.delete.mode=merge-on-read on v2 tables; copy-on-write stays the default so nothing changes unless a user opts in. v1 (cannot store delete manifests) and v3 (deletion vectors, out of scope) keep the copy-on-write fallback. A size-based heuristic (rewrite tiny files instead of writing delete files) can come later.
Feature Request / Improvement
Transaction.delete()is copy-on-write: deleting rows rewrites every data file that holds a matched row, so it costs ~O(table) per operation and grows with the table. Add v2 merge-on-read position-delete writes so a delete instead writes a small position-delete file, costing O(rows deleted), with the data files left untouched. v2 position deletes are readable by the existing query engines today, so this is broadly adoptable.Even as v3 merge-on-read (deletion vectors) support lands, v2 position-delete writes remain valuable, because format version is a per-table property and the two encodings are mutually exclusive: a v2 table can never use a deletion vector. v3 write support therefore does nothing for the large existing v2 fleet, whose tables stay v2 until deliberately upgraded and often must stay v2 to remain readable by every engine that consumes them (v3 deletion vectors require newer readers). For those tables, position deletes are the only efficient delete path, and they are also the format Java/Spark Iceberg already writes, so this also closes a read/write asymmetry in PyIceberg. Deletion vectors are the right default for new v3 tables; v2 position deletes serve the installed base.
What already exists (no work needed)
POSITIONAL_DELETE_SCHEMA(file_path,pos),DataFileContent.POSITION_DELETES,ManifestContent.DELETES, and the full snapshot / manifest-list / commit machinery.Transaction.delete()already recognizeswrite.delete.mode=merge-on-read. It currently just warns "not yet supported" and falls back to copy-on-write. That fallback is the hook point.The gap to close
posinPOSITIONAL_DELETE_SCHEMAfrominttolong. The Iceberg spec typesposaslong; keeping itintmismatches what other engines write/read and overflows on files with more than 2^31 rows. The read path treatsposas a generic index, so widening is safe.data; a variant is needed that writes contentdeletes.file_pathlower/upper bounds. The read-side delete-file index pins a delete to a single data file only when itsfile_pathbound is exact; the defaulttruncate(16)write-metrics mode would truncate that bound and mis-route (or over-apply) the delete.Transaction.delete(), gated behindwrite.delete.mode=merge-on-readon v2 tables; copy-on-write stays the default so nothing changes unless a user opts in. v1 (cannot store delete manifests) and v3 (deletion vectors, out of scope) keep the copy-on-write fallback. A size-based heuristic (rewrite tiny files instead of writing delete files) can come later.