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

  1. Cast operands to DOUBLE or DECIMAL(p,s) with sufficient precision before adding: CAST(a AS DOUBLE) + CAST(b AS DOUBLE).
  2. Reorder/reduce the computation so intermediate sums stay in range.
  3. Use try_cast or a CASE guard to detect overflow-prone values before adding.
  4. 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

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


AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/243b302bb28728c8. Report an issue: GitHub.