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