+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 >>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://lists.apache.org/thread/ks01jpv40qjlvz4yop5tlqv4x5oxbwy6__;!!LIr3w8kk_Xxm!vsYT4Z_ihSMhUpgRXcXgEUbArKyPoG3WKwSCXmmMtC_0Tg3ICMgaSOoq7WzaKsMaK4-c_vXUCsbXEVhdw7RV0di7e8S-yLUE$> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Huaxin >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>
