+1 (binding) Thanks Huaxin for driving the discussion and thanks everyone for contributing.
On Thu, Aug 13, 2026 at 11:18 AM Xin Huang via dev <[email protected]> wrote: > +1 (non-binding) > > Thanks > > On Thu, Aug 13, 2026 at 11:13 AM Russell Spitzer < > [email protected]> wrote: > >> +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 >>>>>> <https://urldefense.com/v3/__https://lists.apache.org/thread/ks01jpv40qjlvz4yop5tlqv4x5oxbwy6__;!!LIr3w8kk_Xxm!vsYT4Z_ihSMhUpgRXcXgEUbArKyPoG3WKwSCXmmMtC_0Tg3ICMgaSOoq7WzaKsMaK4-c_vXUCsbXEVhdw7RV0di7e8S-yLUE$> >>>>>> >>>>>> Thanks, >>>>>> Huaxin >>>>>> >>>>>
