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