+1 (non-binding) Thanks Huaxin!
On Thu, Aug 13, 2026 at 11:03 Gianluca Graziadei < [email protected]> wrote: > +1 (non-binding ) > > The asymmetric cost argument is the decisive factor for me. > > An equality delete allows the writer to offload work onto every subsequent > read, and this deferred cost is neither bounded nor visible to the party > that generated it. Deletion vectors make that cost explicit and ensure it > is paid only once. > > I would also like to highlight point 3, which I think is underrated: > making the upgrade metadata-only decouples V4 adoption from delete file > migration. Users can move to V4 on their own timeline and convert equality > deletes as a background maintenance task. Coupling the two would have > turned V4 adoption into a weeks-long operational project for large tables. > > Cheers, > > Gianluca > > Il giorno gio 13 ago 2026 alle ore 19:57 Neelesh Salian < > [email protected]> ha scritto: > >> +1 (non binding) Thank you Huaxin. >> >> On Wed, Aug 12, 2026 at 19:07 huaxin gao <[email protected]> wrote: >> >>> Hi all, >>> >>> Following the discussion thread "[DISCUSS] Deprecate Equality Deletes in >>> Iceberg V4" [1], I'd like to call a vote on the following proposal for >>> the >>> V4 table spec. >>> >>> Proposal >>> -------- >>> 1. Writing new equality deletes is forbidden for V4 tables: the V4 >>> metadata >>> will not define equality deletes as an allowed entry type. >>> >>> 2. Reading equality deletes remains supported in the reference >>> implementation for backward compatibility, both for existing V2/V3 >>> tables and for equality deletes carried over into upgraded V4 tables. >>> >>> 3. Upgrading a V2/V3 table to V4 is metadata-only (no synchronous rewrite >>> of data or delete files). Existing equality deletes remain in carried- >>> over V2/V3 delete manifests; converting them to deletion vectors is a >>> separate, optional maintenance action. >>> >>> Rationale >>> --------- >>> Equality deletes impose an asymmetric cost paid on every read, complicate >>> the format, and block features such as CDC, row lineage, and incremental >>> index/materialized-view maintenance. Deletion vectors make deletion a >>> flat, >>> one-time cost, and the Flink ConvertEqualityDeletes work demonstrates a >>> viable replacement path, so we do not need the full replacement completed >>> before forbidding new equality deletes in V4. >>> >>> The vote will be open for at least 72 hours. >>> >>> [ ] +1 Forbid writing equality deletes in V4 >>> [ ] +0 >>> [ ] -1 Do not forbid (please explain) >>> >>> [1] https://lists.apache.org/thread/ks01jpv40qjlvz4yop5tlqv4x5oxbwy6 >>> >>> Thanks, >>> Huaxin >>> >>
