Hi Yang, Thank you for the review and for your kind words.
Regarding the "rb64_" prefix, I agree. Using "rb64_" (e.g., rb64_build_agg, rb64_cardinality) aligns well with pg_roaringbitmap conventions and creates a clean separation between the 32-bit and 64-bit function families. I have updated the "Future Work" section to reflect this naming direction. I also agree with adding rb_or and rb_and scalars to Phase 1. Since these are fundamental set operations, they belong in Phase 1 alongside the other scalar functions. I have added rb_or(BYTES, BYTES) → BYTES and rb_and(BYTES, BYTES) → BYTES to the Phase 1 function table. Best regards, Prajwal Banakar On Thu, 23 Apr 2026 at 11:28, Yang Wang <[email protected]> wrote: > Hi Prajwal, > > Thank you for your outstanding work in driving this forward. I fully agree > with the conclusions reached in our recent discussions. I just have two > minor suggestions to add: > > For the 64-bit function family, I suggest using the 'rb64_' prefix (e.g., > rb64_build_agg). This aligns well with PostgreSQL’s naming conventions. > Looking ahead, we could adopt a consistent style for type handling as > well—for instance, using BITMAP to refer to the 32-bit type and BITMAP64 > for the 64-bit encoded type. > > Additionally, for the functions introduced in Phase 1, it would be > beneficial to include scalar versions of rb_and and rb_or. > > Best regards, > Yang > > Prajwal Banakar <[email protected]> 于2026年3月1日周日 14:20写道： > > > Hi everyone, > > > > I would like to start a discussion on the proposal for Native Bitmap > > Integration & Stateless Pushdown Aggregation. > > > > This proposal enables end-to-end native support for the BITMAP type in > > Fluss and integrates it with the existing aggregation merge engine to > > support server-side bitmap union pushdown. The goal is to reduce network > > transfer and offload DISTINCT-style aggregation from Flink to the > > TabletServer. > > > > Key highlights of the proposal include: > > > > - Type System: Promoting BITMAP to a first-class logical type. > > - UDF Suite: Introducing BITMAP_BUILD, BITMAP_OR_AGG, and > > BITMAP_CARDINALITY (aligned with FLIP-556 and StarRocks semantics). > > - Optimizer: Planner-based pushdown via applyAggregates in the Flink > > connector. > > - Safety: No changes to LogRecordBatch or WAL, making this strictly > > additive and migration-free. > > > > You can find the full proposal document here: > > > > > https://docs.google.com/document/d/1sDhfkmo-w-UTvo2n3rsY1lytSSryswfkI83cSdka8s0/edit?usp=sharing > > > > I would appreciate feedback on the public interfaces, pushdown > constraints, > > and overall scope. > > > > Best regards, > > Prajwal Banakar > > >
