lucasfang opened a new issue, #335:
URL: https://github.com/apache/paimon-cpp/issues/335

   ## Search before asking
   
   - [x] I searched in the 
[issues](https://github.com/apache/paimon-cpp/issues) and found nothing similar.
   
   ## Motivation
   
   Two predicate leaf functions evaluate a batch by running an `arrow::compute` 
kernel and reading back the `arrow::BooleanArray` it writes: 
`MultiLiteralsLeafFunction` (`IN` / `NOT IN`, via `IsIn`) and 
`NullFalseLeafBinaryFunction` (the comparison functions). A kernel returns a 
bitmap, one bit per row, but `LeafFunction::Test` returns `std::vector<char>`, 
one byte per row, so both call sites spread the bits over bytes with the same 
per-row loop: test `IsNull`, read `Value`, apply the negation `NOT IN` needs, 
store a byte. That is a shift, a mask and a byte store per row, duplicated 
across the two call sites, on the selection path every filtered batch goes 
through.
   
   ## Solution
   
   Extract the spread into one helper, 
`ArrowUtils::UnpackBooleansToBytes(array, negate)`, and read the bitmap a byte 
at a time instead of a bit at a time:
   
   - A compile-time table maps each of the 256 bitmap bytes to the eight bytes 
it expands to, so the aligned body produces eight rows per iteration with one 
lookup and one 8-byte store.
   - A scalar head and tail cover the rows sharing a partial leading or 
trailing byte, which is where the array offset is not byte-aligned; a batch a 
kernel has just written is aligned, so it takes the fast body throughout.
   - The offset and the validity bitmap are honoured exactly as 
`BooleanArray::Value()` and `Array::IsValid()` honour them, and a null row 
unpacks to 0 whatever the value bitmap holds for it, which is what both `IN` / 
`NOT IN` and every `NullFalseLeafBinaryFunction` require.
   
   `MultiLiteralsLeafFunction` passes its `negate` through; 
`NullFalseLeafBinaryFunction` passes `negate=false`. The bytes each returns are 
unchanged.
   
   ## Anything else?
   
   A property test that asserts the helper equals a row-by-row reference 
through the very accessors it replaces, over every `(offset, length)` slice of 
a bitmap whose value and null periods are not multiples of eight and both 
negate values, pins the offset, validity and negate handling against the 
definitions it optimizes. No change to any header under `include/paimon/`, the 
storage format, or the protocol: `ArrowUtils` is an internal utility under 
`src/paimon/common/utils/arrow/`.
   
   ## Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to