prestodb/presto · error · PrestoException

NOT_SUPPORTED

NOT_SUPPORTED

Error message

statement is too large (stack overflow during analysis)

What it means

When analyzing/planning a query, deep recursion over the expression tree exhausted the JVM stack. Presto catches the StackOverflowError during logical plan creation and rethrows it as a NOT_SUPPORTED PrestoException indicating the statement is too large.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/execution/SqlQueryExecution.java:635

            // extract output
            Optional<Output> output = new OutputExtractor().extractOutput(plan.getRoot());
            stateMachine.setOutput(output);

            // fragment the plan
            // the variableAllocator is finally passed to SqlQueryScheduler for runtime cost-based optimizations
            variableAllocator.set(new VariableAllocator(plan.getTypes().allVariables()));
            SubPlan fragmentedPlan = getSession().getRuntimeStats().recordWallAndCpuTime(
                    FRAGMENT_PLAN_TIME_NANOS,
                    () -> planFragmenter.createSubPlans(stateMachine.getSession(), plan, false, idAllocator, variableAllocator.get(), stateMachine.getWarningCollector()));

            // record analysis time
            stateMachine.endAnalysis();

            boolean explainAnalyze = queryAnalysis.isExplainAnalyzeQuery();
            return new PlanRoot(fragmentedPlan, !explainAnalyze, queryAnalysis.extractConnectors());
        }
        catch (StackOverflowError e) {
            throw new PrestoException(NOT_SUPPORTED, "statement is too large (stack overflow during analysis)", e);
        }
        catch (InvalidFunctionArgumentException e) {
            throw new PrestoException(INVALID_FUNCTION_ARGUMENT, e.getMessage(), e);
        }
    }

    private PlanRoot runCreateLogicalPlanAsync()
    {
        try {
            // Check if creating plan async has been cancelled
            if (planFutureLocked.compareAndSet(false, true)) {
                return createLogicalPlanAndOptimize();
            }
            return null;
        }
        catch (Throwable e) {
            fail(e);
            throw e;

View on GitHub (pinned to 55bb57d202)

Solutions

1. Split the query into smaller queries and combine results client-side.
2. Rewrite huge OR chains into an IN list or a temporary table + JOIN.
3. Reduce subquery nesting depth by flattening or using CTEs.
4. Increase -Xss thread stack size as a workaround, though this only delays the limit.

Example fix

-- before
SELECT * FROM t WHERE a=1 OR a=2 OR ... (10000 terms);
-- after
SELECT * FROM t WHERE a IN (1,2,...); -- or load values into a temp table and JOIN

// client-side: approximate expression depth before sending
countNestedOps(sql) > 1000 ? reject("query too deep") : send(sql);

// catch PrestoException with errorCode NOT_SUPPORTED and message containing 'stack overflow during analysis'; split the query and retry

When it happens

Trigger: doCreateLogicalPlanAndOptimize() in SqlQueryExecution hits StackOverflowError while analyzing a statement with an extremely deep expression tree — e.g. thousands of nested OR/AND conditions, huge IN lists, or deeply nested subqueries.

Common situations: ORMs or query builders generating giant predicates, dynamically generated WHERE clauses with thousands of terms, machine-generated SQL, or very long chained CASE expressions.

Understand the failure class

Background: Presto NOT_SUPPORTED error: what "not supported" means and how to fix it — this error's family across 3 libraries.

Related errors

• ${name} is too large (stack overflow while parsing)
• INVALID_TABLE_PROPERTY
• MISSING_ATTRIBUTE
• AMBIGUOUS_ATTRIBUTE
• NOT_SUPPORTED

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