prestodb/presto · error · PrestoException
NUMERIC_VALUE_OUT_OF_RANGE
NUMERIC_VALUE_OUT_OF_RANGE
Error message
bigint addition overflow: %s + %s
What it means
BigintOperators.add computes bigint addition with Math.addExact and wraps ArithmeticException in a PrestoException with NUMERIC_VALUE_OUT_OF_RANGE when the result exceeds the 64-bit bigint range [Long.MIN_VALUE, Long.MAX_VALUE]. Presto never silently wraps bigint arithmetic; overflow is an explicit error.
Source
Thrown at presto-main-base/src/main/java/com/facebook/presto/type/BigintOperators.java:76
import static java.lang.Float.floatToRawIntBits;
import static java.lang.Math.toIntExact;
import static java.lang.String.format;
public final class BigintOperators
{
private BigintOperators()
{
}
@ScalarOperator(ADD)
@SqlType(StandardTypes.BIGINT)
public static long add(@SqlType(StandardTypes.BIGINT) long left, @SqlType(StandardTypes.BIGINT) long right)
{
try {
return Math.addExact(left, right);
}
catch (ArithmeticException e) {
throw new PrestoException(NUMERIC_VALUE_OUT_OF_RANGE, format("bigint addition overflow: %s + %s", left, right), e);
}
}
@ScalarOperator(SUBTRACT)
@SqlType(StandardTypes.BIGINT)
public static long subtract(@SqlType(StandardTypes.BIGINT) long left, @SqlType(StandardTypes.BIGINT) long right)
{
try {
return Math.subtractExact(left, right);
}
catch (ArithmeticException e) {
throw new PrestoException(NUMERIC_VALUE_OUT_OF_RANGE, format("bigint subtraction overflow: %s - %s", left, right), e);
}
}
@ScalarOperator(MULTIPLY)
@SqlType(StandardTypes.BIGINT)
public static long multiply(@SqlType(StandardTypes.BIGINT) long left, @SqlType(StandardTypes.BIGINT) long right)View on GitHub (pinned to 55bb57d202)
Solutions
- Cast operands to DOUBLE or DECIMAL(p,s) with sufficient precision before adding: CAST(a AS DOUBLE) + CAST(b AS DOUBLE).
- Reorder/reduce the computation so intermediate sums stay in range.
- Use try_cast or a CASE guard to detect overflow-prone values before adding.
- If many values are summed, consider approx_percentile/approxDistinct style alternatives or store data as DECIMAL.
Example fix
// before SELECT balance + reward FROM accounts; -- overflow when near Long.MAX_VALUE // after SELECT CAST(balance AS DECIMAL(38,0)) + CAST(reward AS DECIMAL(38,0)) FROM accounts;
Defensive patterns
Strategy: validation
Validate before calling
-- Guard against overflow before adding bigints
SELECT a + b
FROM t
WHERE CAST(a AS DECIMAL(38,0)) + CAST(b AS DECIMAL(38,0))
BETWEEN -9223372036854775808 AND 9223372036854775807; Type guard
boolean safeAdd(long a, long b) {
return b > 0 ? a <= Long.MAX_VALUE - b : a >= Long.MIN_VALUE - b;
} Try / catch
try {
return BigintOperators.add(left, right);
} catch (PrestoException e) {
if (e.getErrorCode().getCode() == StandardErrorCode.NUMERIC_VALUE_OUT_OF_RANGE.toErrorCode().getCode()) {
// fall back to DECIMAL/DOUBLE arithmetic or surface a user-friendly overflow message
} else {
throw e;
}
} Prevention
- Cast to DECIMAL/DOUBLE when values may approach Long.MAX_VALUE.
- Range-check operand columns before arithmetic with CASE or WHERE filters.
- Remember Presto bigint arithmetic errors instead of wrapping around.
- Store extreme counters/ids as DECIMAL from the start.
When it happens
Trigger: Executing SQL 'left + right' on two BIGINT operands whose mathematical sum is outside the signed 64-bit range, e.g. 9223372036854775807 + 1. Called from generated query input paths (aggregations, arithmetic in projections/filters).
Common situations: Summing large values in aggregations where the total exceeds bigint range; adding timestamps-as-bigint (epoch millis) to large offsets; counters or ids near Long.MAX_VALUE; porting code from languages with silent overflow.
Related errors
- NUMERIC_VALUE_OUT_OF_RANGE
- NUMERIC_VALUE_OUT_OF_RANGE
- NUMERIC_VALUE_OUT_OF_RANGE
- INVALID_CAST_ARGUMENT
- NUMERIC_VALUE_OUT_OF_RANGE
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/243b302bb28728c8.
Report an issue: GitHub.