thswlsqls opened a new issue, #9863: URL: https://github.com/apache/paimon/issues/9863
**Search before asking** - [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. **Paimon version** master @ bbae07d37 **Compute Engine** Any engine writing `TIMESTAMP(9)` / `TIMESTAMP_LTZ(9)` columns (Flink, Java API); Spark's microsecond default is unaffected. **Minimal reproduce step** 1. Create a table with `f1 TIMESTAMP(9)` and `file-index.bitmap.columns = f1`. 2. Insert two rows whose `f1` differ only below a microsecond, e.g. `...00.000123000` and `...00.000123400`. 3. `SELECT * FROM t WHERE f1 <> TIMESTAMP '...00.000123000'`. Expected 1 row, got 0. `BitmapFileIndex.getValueMapper()` keys TIMESTAMP / TIMESTAMP_LTZ through `Timestamp.toMicros()`, so both rows share one key; `Reader.visitNotIn` flips that bitmap and `RawFileSplitRead` applies it as an exact row selection, dropping the whole bucket. **What doesn't meet your expectations?** `<>` / `NOT IN` on an indexed `TIMESTAMP(7..9)` column must return the same rows as an unindexed scan. #9654 fixed this for BSI (`REMAIN` for value predicates, exact `IS NULL` / `IS NOT NULL`); bitmap has used the same mapper since #3775; range-bitmap rejects precision > 6 at build time. **Anything else?** N/A **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]
