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