[thswlsqls]

Purpose

fix #10728

• Affects only FLOAT/DOUBLE columns listed in mosaic.stats-columns; the default collects no stats.
• Native float min/max use a partial comparison: a leading NaN pins both bounds to NaN, and -0.0 equals +0.0. Manifest and row-group pruning can then skip matching rows.
• FLOAT/DOUBLE now keep only null counts at both levels (documented in fileformat.md), losing min/max pruning.
• ORC [format] Drop ORC float bounds that hide NaN or -0.0 #10337 drops only detectable cases; Mosaic has no NaN count, so a non-leading NaN is undetectable.
• fix(core): ignore NaN when tracking min/max column statistics paimon-mosaic#83 (open) cannot fix already-written files.

Tests

• Added MosaicFloatingPointBoundsTest: table reads with NaN-first and signed-zero rows (FLOAT and DOUBLE), asserting the planned split, the row-group read and the filtered result. Red on master at both levels, green now. Single row group only; engine SQL not run.
• Updated MosaicSimpleStatsExtractorTest expectations.
• mvn -pl paimon-mosaic clean install: 162 tests, 0 failures.

[JingsongLi]

There is an existing-data upgrade gap in the manifest-level fix. MosaicSimpleStatsExtractor drops these bounds when metadata is created, but AppendOnlyFileStoreScan.filterByStats reads the already-persisted entry.file().valueStats() without re-extracting it. Files written before this change can therefore still be pruned before the fixed MosaicRecordsReader is reached.

I reproduced this for both FLOAT and DOUBLE: write [NaN, -5, 3] with the pre-fix extractor behavior and mosaic.stats-columns=v, then read with the fixed behavior and v < 0. Reading the unfiltered split with the fixed reader returns row 2, while the normal filtered scan plans zero splits. The 162 existing module tests pass, but this upgrade regression test fails for both types.

This is a remaining failure of the original bug, rather than a new regression introduced here. Before treating this as a production fix for existing tables, please cover persisted unsafe manifest statistics as well, or explicitly document the limitation and a verified procedure for rebuilding the affected metadata/data. Please add a test that writes legacy bounds and reads them with the fix; the current tests write all metadata using the new extractor.

[JingsongLi]

No one has actually encountered a "NaN" issue; stop trying to use AI to "fix" such problems—unless you are genuinely facing them in a production environment.