+1 binding, thanks Huaxin On Fri, Aug 21, 2026 at 10:11 AM huaxin gao <[email protected]> wrote:
> 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 >> > >> >> > > >> > >> >
