I’d like to offer a perspective on compatibility. If the design is robust and reasonable, it is certainly welcomed. However, if the design falls short, it becomes a compromise—not just for Iceberg users, but for the entire ecosystem.
I look forward to hearing your thoughts on this. Yufei On Fri, Oct 11, 2024 at 9:06 PM Manu Zhang <owenzhang1...@gmail.com> wrote: > Hi Ryan, > > Do you mean the doc Improve Position Deletes in V3 > <https://docs.google.com/document/d/18Bqhr-vnzFfQk1S4AgRISkA_5_m5m32Nnc2Cw0zn2XM/edit?tab=t.0> > by > Anton? I don't recall Anton used the term "deletion vector" in his > proposal. > > On Sat, Oct 12, 2024 at 12:30 AM Micah Kornfield <emkornfi...@gmail.com> > wrote: > >> I think it might be worth mentioning the current proposal makes some, >> mostly minor, design choices to try to be compatible with Delta Lake >> deletion vectors. I think there might be a general philosophical question >> on what compromises the community is willing to make for compatibility >> reasons. >> >> On Thu, Oct 10, 2024 at 2:42 PM rdb...@gmail.com <rdb...@gmail.com> >> wrote: >> >>> Hi everyone, >>> >>> There seems to be broad agreement around Anton's proposal to use >>> deletion vectors in Iceberg v3, so I've opened two PRs that update the spec >>> with the proposed changes. The first, PR #11238 >>> <https://github.com/apache/iceberg/pull/11238/files>, adds a new Puffin >>> blob type, delete-vector-v1, that stores a delete vector. The second, PR >>> #11240 <https://github.com/apache/iceberg/pull/11240/files>, updates >>> the Iceberg table spec. >>> >>> Please take a look and comment! >>> >>> Ryan >>> >>
