lxy-9602 commented on PR #323:
URL: https://github.com/apache/paimon-cpp/pull/323#issuecomment-5630380548

   Thanks for the contribution and the performance improvement. Could we 
refactor this before merging?
   
   Java’s `ManifestAvroReader` only uses the top-level `bucket` and 
`totalBuckets` fields for filtering. I’m not sure why `_FILE._SCHEMA_ID` is 
needed here, since `bucket-key` is immutable. Schema ID also seems too broad as 
a bucket-layout identifier.
   
   Could we reuse or extend the existing late-materialization framework instead 
of implementing another probe/bitmap/reread flow in `ManifestFile`? The 
selector is roughly:
   
   ```text
   _BUCKET = target
   OR _TOTAL_BUCKETS IS NULL
   OR _TOTAL_BUCKETS != expectedTotalBuckets
   ```
   
   `_VERSION = 2` may still be validated for every row.
   
   This would also keep Manifest-specific logic out of the generic Avro reader.


-- 
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