Close the vote with 3 bindings: - Penghui Li - Lari Hotari - Yunze Xu Thanks for you review and vote!
Tao Jiuming(dao-jun) PengHui Li <peng...@apache.org> 于2025年3月5日周三 10:57写道： > +1 binding > > - Penghui > > On Mon, Mar 3, 2025 at 2:28 AM Tao Jiuming <dao...@apache.org> wrote: > > > bump > > > > Tao Jiuming <dao...@apache.org> 于2025年2月11日周二 14:37写道： > > > > > Hi all, > > > > > > I open PIP-404 to introduce per ledger properties, which will add a > > > `properties` field to `LedgerInfo` to store extra properties for every > > > `Ledger`. > > > > > > # Background knowledge > > > As we don't have a secondary index on the Bookkeeper, so we can't query > > > entries by message metadata efficiently. > > > The `ManagedCursor` provides a method `asyncFindNewestMatching` to find > > > the newest entry that matches the given > > > predicate by binary search(See `OpFindNewest.java`). > > > In https://github.com/apache/pulsar/pull/22792, we optimized `seeking > by > > > timestamp` by calculating > > > the range of ledgers that may contain the target timestamp by > > > `LedgerInfo#timestamp` and we don't need to scan all > > > ledgers. > > > However, when we enabled `AppendIndexMetadataInterceptor` and we want > to > > > query entries by `BrokerEntryMetadata#index`, > > > there is no more efficient way, > > > we have to scan all ledgers by binary search to find the target entry. > > > > > > # Motivation > > > Introduce per-ledger properties and we can store the extra per-ledger > > > properties in the `LedgerInfo`, > > > so we can query entries by `incremental index` more efficiently, say, > > > `BrokerEntryMetadata#index`. > > > > > > PR link: https://github.com/apache/pulsar/pull/23837/files > > > > > > Please help review the PIP and vote. > > > > > > Thanks, > > > Tao Jiuming(dao-jun) > > > > > >
