+1 (non-binding) On Sat, Aug 15, 2026 at 11:32 PM Maximilian Michels <[email protected]> wrote: > > +1 (non-binding) > > Thanks, > Max > > Szehon Ho <[email protected]> schrieb am Fr. 14. Aug. 2026 um 22:07: >> >> +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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Huaxin >>>>>>>> >>>>>>>>
-- Regards Junwang Zhao
