+1 (binding) On Thu, Aug 13, 2026 at 1:07 PM Hongyue Zhang <[email protected]> wrote:
> +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 >>>> >>>
