+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 >>>>>>>>>>>> >>>>>>>>>>> >>>
