An 8-byte integer data type used in `CREATE TABLE`

and `ALTER TABLE`

statements.

**Syntax:**

In the column definition of a `CREATE TABLE`

statement:

`column_name` BIGINT

**Range:** -9223372036854775808 .. 9223372036854775807. There is no `UNSIGNED`

subtype.

**Conversions:** Impala automatically converts to a floating-point type (`FLOAT`

or
`DOUBLE`

) automatically. Use `CAST()`

to convert to `TINYINT`

,
`SMALLINT`

, `INT`

, `STRING`

, or `TIMESTAMP`

.
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.

**Examples:**

```
CREATE TABLE t1 (x BIGINT);
SELECT CAST(1000 AS BIGINT);
```

**Usage notes:**

`BIGINT`

is a convenient type to use for column declarations because you can use any kind of
integer values in `INSERT`

statements and they are promoted to `BIGINT`

where
necessary. However, `BIGINT`

also requires the most bytes of any integer type on disk and in
memory, meaning your queries are not as efficient and scalable as possible if you overuse this type.
Therefore, prefer to use the smallest integer type with sufficient range to hold all input values, and
`CAST()`

when necessary to the appropriate type.

For a convenient and automated way to check the bounds of the `BIGINT`

type, call the
functions `MIN_BIGINT()`

and `MAX_BIGINT()`

.

If an integer value is too large to be represented as a `BIGINT`

, use a
`DECIMAL`

instead with sufficient digits of precision.

**NULL considerations:** Casting any non-numeric value to this type produces a `NULL`

value.

**Partitioning:** Prefer to use this type for a partition key column. Impala can process the numeric
type more efficiently than a `STRING`

representation of the value.

**HBase considerations:** This data type is fully compatible with HBase 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.

**Added in:** Available in all versions of Impala.

**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.

**Sqoop considerations:**

If you use Sqoop to
convert RDBMS data to Parquet, be careful with interpreting any
resulting values from `DATE`

, `DATETIME`

,
or `TIMESTAMP`

columns. The underlying values are
represented as the Parquet `INT64`

type, which is
represented as `BIGINT`

in the Impala table. The Parquet
values represent the time in milliseconds, while Impala interprets
`BIGINT`

as the time in seconds. Therefore, if you have
a `BIGINT`

column in a Parquet table that was imported
this way from Sqoop, divide the values by 1000 when interpreting as the
`TIMESTAMP`

type.

**Related information:**

Numeric Literals, TINYINT Data Type, SMALLINT Data Type, INT Data Type, BIGINT Data Type, DECIMAL Data Type (Impala 3.0 or higher only), Impala Mathematical Functions