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