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 >
