+1 Regards, Viquar Khan
On Thu, Aug 13, 2026, 3:04 PM Steven Wu <[email protected]> wrote: > +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 >>>>>>> >>>>>>
