# DOUBLE Data Type

A double precision floating-point data type used in `CREATE TABLE`

and ```
ALTER
TABLE
```

statements.

**Syntax:**

In the column definition of a `CREATE TABLE`

statement:

`column_name` DOUBLE

**Range:** 4.94065645841246544e-324d .. 1.79769313486231570e+308, positive or negative

**Precision:** 15 to 17 significant digits, depending on usage. The number of significant digits does
not depend on the position of the decimal point.

**Representation:** The values are stored in 8 bytes, using
IEEE 754 Double Precision Binary Floating Point format.

**Conversions:** Impala does not automatically convert `DOUBLE`

to any other type. You can
use `CAST()`

to convert `DOUBLE`

values to `FLOAT`

,
`TINYINT`

, `SMALLINT`

, `INT`

, `BIGINT`

,
`STRING`

, `TIMESTAMP`

, or `BOOLEAN`

. You can use exponential
notation in `DOUBLE`

literals or when casting from `STRING`

, for example
`1.0e6`

to represent one million.
Casting an integer or floating-point value `N`

to
`TIMESTAMP`

produces a value that is `N`

seconds past the start of the epoch
date (January 1, 1970). By default, the result value represents a date and time in the UTC time zone.
If the setting `-use_local_tz_for_unix_timestamp_conversions=true`

is in effect,
the resulting `TIMESTAMP`

represents a date and time in the local time zone.

**Usage notes:**

The data type `REAL`

is an alias for `DOUBLE`

.

Impala does not evaluate NaN (not a number) as equal to any other numeric values,
including other NaN values. For example, the following statement, which evaluates equality
between two NaN values, returns `false`

:

```
SELECT CAST('nan' AS DOUBLE)=CAST('nan' AS DOUBLE);
```

**Examples:**

```
CREATE TABLE t1 (x DOUBLE);
SELECT CAST(1000.5 AS DOUBLE);
```

**Partitioning:** Because fractional values of this type are not always represented precisely, when this
type is used for a partition key column, the underlying HDFS directories might not be named exactly as you
expect. Prefer to partition on a `DECIMAL`

column instead.

**HBase considerations:** This data type is fully compatible with HBase tables.

**Parquet considerations:** This type is fully compatible with Parquet tables.

**Text table considerations:** Values of this type are potentially larger in text tables than in tables
using Parquet or other binary formats.

**Internal details:** Represented in memory as an 8-byte value.

**Column statistics considerations:** Because this type has a fixed size, the maximum and average size
fields are always filled in for column statistics, even before you run the `COMPUTE STATS`

statement.

**Restrictions:**

Due to the way arithmetic on `FLOAT`

and `DOUBLE`

columns uses
high-performance hardware instructions, and distributed queries can perform these operations in different
order for each query, results can vary slightly for aggregate function calls such as `SUM()`

and `AVG()`

for `FLOAT`

and `DOUBLE`

columns, particularly on
large data sets where millions or billions of values are summed or averaged. For perfect consistency and
repeatability, use the `DECIMAL`

data type for such operations instead of
`FLOAT`

or `DOUBLE`

.

The inability to exactly represent certain floating-point values means that
`DECIMAL`

is sometimes a better choice than `DOUBLE`

or `FLOAT`

when precision is critical, particularly when
transferring data from other database systems that use different representations
or file formats.

**Kudu considerations:**

Currently, the data types `BOOLEAN`

, `FLOAT`

,
and `DOUBLE`

cannot be used for primary key columns in Kudu tables.

**Related information:**

Numeric Literals, Impala Mathematical Functions, FLOAT Data Type