Todd Lipcon has posted comments on this change.
Change subject: KUDU-1386 NaN float and double values are not handled correctly
Patch Set 1:
Line 53: NONCOMPARABLE = 12
> I agree more with Dan, though I think the Todd/Postgres position is reasona
> I'm not following, why would you want NaNs to show up in a per-block min/max
Imagine a column for a time series value which is a float with lots of NaNs.
The user wants to 'select * where !isNan(val)'. In that case, with min/max
statistics, you can just convert this to '< NaN', and quickly use the min/max
to determine whether a given block has any NaNs.
The whole concept of min/max gets a bit messed up if there is no total order.
In terms of compatibility, Oracle also does like Postgres:
"Comparison operators conform, except for comparisons with NaN. Oracle orders
NaN greatest with respect to all other values, and evaluates NaN equal to NaN.
See "Floating-Point Conditions"."
Best I can tell, MySQL doesn't support NaN at all.
SQL Server before 2000 would apparently corrupt the database if you inserted
According to that article, SQL Server 2008 just disallowed them.
SQLite seems to coerce NaN to NULL and prevents insertion into a NOT NULL
column (which is also a reasonable position IMO).
DB2 apparently lives in another universe (the IBM one) where there is both a
positive and negative NaN as well as two variants, "signalling" and "quiet"
(what???). But they do assign a total order:
The ordering among the different special values is as follows: -NAN < -SNAN <
-INFINITY < 0 < INFINITY < SNAN <NAN
So, I think despite there being an IEEE standard around float comparison, I
can't seem to find any database engines which behave that way.
To view, visit http://gerrit.cloudera.org:8080/3142
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Owner: Will Berkeley <wdberke...@gmail.com>
Gerrit-Reviewer: Dan Burkert <d...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
Gerrit-Reviewer: Will Berkeley <wdberke...@gmail.com>