LuciferYang opened a new issue, #67773: URL: https://github.com/apache/doris/issues/67773
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Description `ZoneMap::has_nan` is `optional bool = 8` in `ZoneMapPB` (`gensrc/proto/segment_v2.proto`), added by #55633 together with the NaN handling in the zone map writer. `ZoneMap::from_proto` (`be/src/storage/index/zone_map/zone_map_index.cpp`) reads it unconditionally, so a zone map serialized before that field existed deserializes with `has_nan == false`. Nothing checks `has_has_nan()`, and there is no segment-version gate. Every consumer that treats `has_nan == false` as "no NaN in this zone" therefore trusts bounds that may omit one. `range_stats_usable_for_zonemap` (`be/src/exprs/expr_zonemap_filter.cpp`) is one; #55633 also taught the older olap predicate path to trust the same flag, so this is not limited to expression zone maps. Concretely: a FLOAT page written before #55633 holding `{1.0, NaN, 2.0}` stores bounds `[1.0, 2.0]` with the field absent, because the generic min/max path never selects a NaN. After an upgrade, `WHERE d > 3.0` prunes the page, but Doris orders NaN above every other value, so that row satisfies the predicate and should have been returned. What I have not established is whether any deployment still reads pre-#55633 segments. That decides the severity, and it is not something the code can answer. ### Solution Treat a FLOAT or DOUBLE `ZoneMapPB` with field 8 absent as unusable for range pruning, distinguishing "no NaN" from "unknown", the same way the Parquet readers already distinguish those two with `floating_nan_count_unknown`. The fix belongs at the `from_proto` or index-meta layer so that every consumer inherits it. ### Are you willing to submit PR? - [X] Yes I am 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
