+1(binding) Yufei
On Thu, Aug 13, 2026 at 1:11 PM vaquar khan <[email protected]> wrote: > +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 >>>>>>>> >>>>>>>
