I will submit a PR soon for the spec change. Thanks, Huaxin
On Fri, Aug 21, 2026 at 7:12 AM Xiening Dai <[email protected]> wrote: > Thanks for organizing the vote. Since we have a result now, do we plan to > update the spec? > > On 2026/08/18 06:37:25 huaxin gao wrote: > > The vote passes with 7 binding +1's and 17 non-binding +1's, and no 0 or > > -1's. > > > > Thanks everyone for the voting and discussion! > > > > Best, > > Huaxin > > > > On Tue, Aug 18, 2026 at 4:24 AM Daniel Weeks <[email protected]> wrote: > > > > > +1 (binding) > > > > > > On Sat, Aug 15, 2026 at 9:06 AM Junwang Zhao <[email protected]> > wrote: > > > > > >> +1 (non-binding) > > >> > > >> On Sat, Aug 15, 2026 at 11:32 PM Maximilian Michels <[email protected]> > > >> wrote: > > >> > > > >> > +1 (non-binding) > > >> > > > >> > Thanks, > > >> > Max > > >> > > > >> > Szehon Ho <[email protected]> schrieb am Fr. 14. Aug. 2026 um > > >> 22:07: > > >> >> > > >> >> +1 > > >> >> > > >> >> Thanks > > >> >> Szehon > > >> >> > > >> >> On Fri, Aug 14, 2026 at 10:56 AM Matt Butrovich < > [email protected]> > > >> wrote: > > >> >>> > > >> >>> +1 (non-binding) > > >> >>> > > >> >>> Thanks Huaxin! > > >> >>> > > >> >>> -Matt > > >> >>> > > >> >>> On Fri, Aug 14, 2026 at 9:34 AM Talat Uyarer via dev < > > >> [email protected]> wrote: > > >> >>>> > > >> >>>> +1 non-binding > > >> >>>> > > >> >>>> > > >> >>>> On Thu, Aug 13, 2026 at 8:31 PM Alex Stephen via dev < > > >> [email protected]> wrote: > > >> >>>>> > > >> >>>>> +1 non-binding > > >> >>>>> > > >> >>>>> Thanks for driving this! > > >> >>>>> > > >> >>>>> On Thu, Aug 13, 2026 at 7:17 PM Gang Wu <[email protected]> > wrote: > > >> >>>>>> > > >> >>>>>> +1 (non-binding) > > >> >>>>>> > > >> >>>>>> On Fri, Aug 14, 2026 at 9:37 AM Manu Zhang < > > >> [email protected]> wrote: > > >> >>>>>>> > > >> >>>>>>> +1 (non-binding) > > >> >>>>>>> > > >> >>>>>>> Thanks Huaxin! > > >> >>>>>>> > > >> >>>>>>> On Fri, Aug 14, 2026 at 7:06 AM Bryan Keller < > [email protected]> > > >> wrote: > > >> >>>>>>>> > > >> >>>>>>>> +1 non-binding > > >> >>>>>>>> > > >> >>>>>>>> On Aug 13, 2026, at 3:55 PM, Andrei Tserakhau via dev < > > >> [email protected]> wrote: > > >> >>>>>>>> > > >> >>>>>>>> +1 (non-binding) > > >> >>>>>>>> > > >> >>>>>>>> On Fri, Aug 14, 2026 at 12:16 AM Yufei Gu < > [email protected]> > > >> wrote: > > >> >>>>>>>>> > > >> >>>>>>>>> +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 > > >> >>>>>>>>>>>>>>>>> > > >> >>>>>>>>>>>>>>>>> Thanks, > > >> >>>>>>>>>>>>>>>>> Huaxin > > >> >>>>>>>> > > >> >>>>>>>> > > >> > > >> > > >> -- > > >> Regards > > >> Junwang Zhao > > >> > > > > > >
