+1 (binding) On Sat, Aug 15, 2026 at 9:06 AM Junwang Zhao <[email protected]> wrote:
> +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 >
