yashmayya commented on PR #13758: URL: https://github.com/apache/pinot/pull/13758#issuecomment-2272643650
> do we have a contract that the null bitmap can never be empty It does look like the `NullValueVectorCreator` only creates the null value vector file on disk if the bitmap is not empty - https://github.com/apache/pinot/blob/ee4049e1e80bc2521242dd523236f81549e03222/pinot-segment-local/src/main/java/org/apache/pinot/segment/local/segment/creator/impl/nullvalue/NullValueVectorCreator.java#L69-L78 And even though the mutable null value vector reader could return an empty bitmap, I see some places like in `ProjectionBlockValSet` where that is handled and a null bitmap is returned if empty - https://github.com/apache/pinot/blob/ee4049e1e80bc2521242dd523236f81549e03222/pinot-core/src/main/java/org/apache/pinot/core/operator/docvalsets/ProjectionBlockValSet.java#L65-L67 Seems like an implicit contract but I guess it shouldn't be much of an issue either way since the `RoaringBitmap::isEmpty` method is O(1) time complexity? > rather than compute its cardinality (worst case linear time) Ah thanks, I hadn't looked too closely at the implementation and didn't realize that it could be worst case linear time. In that case, I'm not sure if this optimization makes much sense. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org For additional commands, e-mail: commits-h...@pinot.apache.org
