+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 >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://lists.apache.org/thread/ks01jpv40qjlvz4yop5tlqv4x5oxbwy6__;!!LIr3w8kk_Xxm!vsYT4Z_ihSMhUpgRXcXgEUbArKyPoG3WKwSCXmmMtC_0Tg3ICMgaSOoq7WzaKsMaK4-c_vXUCsbXEVhdw7RV0di7e8S-yLUE$> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Huaxin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>
