blob: 42edef8ea090960c3b7951de97fadf0d6b96585f [file]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="copyright" content="(C) Copyright 2025" />
<meta name="DC.rights.owner" content="(C) Copyright 2025" />
<meta name="DC.Type" content="concept" />
<meta name="DC.Title" content="FLOAT Data Type" />
<meta name="DC.Relation" scheme="URI" content="../topics/impala_datatypes.html" />
<meta name="prodname" content="Impala" />
<meta name="prodname" content="Impala" />
<meta name="version" content="Impala 3.4.x" />
<meta name="version" content="Impala 3.4.x" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="float" />
<link rel="stylesheet" type="text/css" href="../commonltr.css" />
<title>FLOAT Data Type</title>
</head>
<body id="float">
<h1 class="title topictitle1" id="ariaid-title1">FLOAT Data Type</h1>
<div class="body conbody">
<p class="p">
A single precision floating-point data type used in <code class="ph codeph">CREATE TABLE</code> and <code class="ph codeph">ALTER
TABLE</code> statements.
</p>
<p class="p">
<strong class="ph b">Syntax:</strong>
</p>
<p class="p">
In the column definition of a <code class="ph codeph">CREATE TABLE</code> statement:
</p>
<pre class="pre codeblock"><code><var class="keyword varname">column_name</var> FLOAT</code></pre>
<p class="p">
<strong class="ph b">Range:</strong> 1.40129846432481707e-45 .. 3.40282346638528860e+38, positive or negative
</p>
<p class="p">
<strong class="ph b">Precision:</strong> 6 to 9 significant digits, depending on usage. The number of significant digits does
not depend on the position of the decimal point.
</p>
<p class="p">
<strong class="ph b">Representation:</strong> The values are stored in 4 bytes, using
<a class="xref" href="https://en.wikipedia.org/wiki/Single-precision_floating-point_format" target="_blank">IEEE 754 Single Precision Binary Floating Point</a> format.
</p>
<p class="p">
<strong class="ph b">Conversions:</strong> Impala automatically converts <code class="ph codeph">FLOAT</code> to more precise
<code class="ph codeph">DOUBLE</code> values, but not the other way around. You can use <code class="ph codeph">CAST()</code> to convert
<code class="ph codeph">FLOAT</code> values to <code class="ph codeph">TINYINT</code>, <code class="ph codeph">SMALLINT</code>, <code class="ph codeph">INT</code>,
<code class="ph codeph">BIGINT</code>, <code class="ph codeph">STRING</code>, <code class="ph codeph">TIMESTAMP</code>, or <code class="ph codeph">BOOLEAN</code>.
You can use exponential notation in <code class="ph codeph">FLOAT</code> literals or when casting from
<code class="ph codeph">STRING</code>, for example <code class="ph codeph">1.0e6</code> to represent one million.
<span class="ph"> Casting an integer or floating-point value
<code class="ph codeph">N</code> to <code class="ph codeph">TIMESTAMP</code> produces a value that is
<code class="ph codeph">N</code> 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 <code class="ph codeph">‑‑use_local_tz_for_unix_timestamp_conversions=true</code>
is in effect, the resulting <code class="ph codeph">TIMESTAMP</code> represents a date and time in the
local time zone. </span>
</p>
<p class="p">
<strong class="ph b">Usage notes:</strong>
</p>
<p class="p">
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 <code class="ph codeph">false</code>:
</p>
<pre class="pre codeblock"><code>
SELECT CAST('nan' AS FLOAT)=CAST('nan' AS FLOAT);
</code></pre>
<p class="p">
<strong class="ph b">Examples:</strong>
</p>
<pre class="pre codeblock"><code>CREATE TABLE t1 (x FLOAT);
SELECT CAST(1000.5 AS FLOAT);
</code></pre>
<p class="p">
<strong class="ph b">Partitioning:</strong> 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
<code class="ph codeph">DECIMAL</code> column instead.
</p>
<p class="p">
<strong class="ph b">HBase considerations:</strong> This data type is fully compatible with HBase tables.
</p>
<p class="p">
<strong class="ph b">Parquet considerations:</strong> This type is fully compatible with Parquet tables.
</p>
<p class="p">
<strong class="ph b">Text table considerations:</strong> Values of this type are potentially larger in text
tables than in tables using Parquet or other binary formats.
</p>
<p class="p">
<strong class="ph b">Internal details:</strong> Represented in memory as a 4-byte value.
</p>
<p class="p">
<strong class="ph b">Column statistics considerations:</strong> 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 <code class="ph codeph">COMPUTE STATS</code> statement.
</p>
<p class="p">
<strong class="ph b">Restrictions:</strong>
</p>
<p class="p">
Due to the way arithmetic on <code class="ph codeph">FLOAT</code> and <code class="ph codeph">DOUBLE</code> 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 <code class="ph codeph">SUM()</code> and <code class="ph codeph">AVG()</code> for
<code class="ph codeph">FLOAT</code> and <code class="ph codeph">DOUBLE</code> columns, particularly on large data
sets where millions or billions of values are summed or averaged. For perfect
consistency and repeatability, use the <code class="ph codeph">DECIMAL</code> data type for such
operations instead of <code class="ph codeph">FLOAT</code> or <code class="ph codeph">DOUBLE</code>.
</p>
<p class="p">
The inability to exactly represent certain floating-point values means that
<code class="ph codeph">DECIMAL</code> is sometimes a better choice than <code class="ph codeph">DOUBLE</code> or
<code class="ph codeph">FLOAT</code> when precision is critical, particularly when transferring data
from other database systems that use different representations or file formats.
</p>
<p class="p">
<strong class="ph b">Kudu considerations:</strong>
</p>
<p class="p">
Currently, the data types <code class="ph codeph">BOOLEAN</code>, <code class="ph codeph">FLOAT</code>, and
<code class="ph codeph">DOUBLE</code> cannot be used for primary key columns in Kudu tables.
</p>
<p class="p">
<strong class="ph b">Related information:</strong>
</p>
<p class="p">
<a class="xref" href="impala_literals.html#numeric_literals">Numeric Literals</a>, <a class="xref" href="impala_math_functions.html#math_functions">Impala Mathematical Functions</a>,
<a class="xref" href="impala_double.html#double">DOUBLE Data Type</a>
</p>
</div>
<div class="related-links">
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a class="link" href="../topics/impala_datatypes.html">Data Types</a></div>
</div>
</div></body>
</html>