prestodb/presto · error · UnsupportedOperationException

Unexpected column type

Error message

Unexpected column type 

What it means

FilteringPageSource.testNonNullPosition applies a filter to a non-null position by dispatching on the column's Type; each supported type family has its own comparison logic. When the column's Type is not one of the supported families (and the filter is not IS_NULL/IS_NOT_NULL, handled before), it throws UnsupportedOperationException 'Unexpected column type'. This indicates a filter/type combination the filtering page source does not implement.

Source

Thrown at presto-hive/src/main/java/com/facebook/presto/hive/FilteringPageSource.java:280

                return filter.testDecimal(block.getLong(position, 0), block.getLong(position, Long.BYTES));
            }
        }

        if (isVarcharType(type) || isCharType(type)) {
            Slice slice = block.getSlice(position, 0, block.getSliceLength(position));
            return filter.testBytes((byte[]) slice.getBase(), (int) slice.getAddress() - ARRAY_BYTE_BASE_OFFSET, slice.length());
        }

        if (type instanceof ArrayType || type instanceof MapType || type instanceof RowType) {
            if (IS_NULL == filter) {
                return block.isNull(position);
            }
            if (IS_NOT_NULL == filter) {
                return !block.isNull(position);
            }
        }

        throw new UnsupportedOperationException("Unexpected column type " + type);
    }

    @Override
    public long getCompletedBytes()
    {
        return delegate.getCompletedBytes();
    }

    @Override
    public long getCompletedPositions()
    {
        return delegate.getCompletedPositions();
    }

    @Override
    public long getReadTimeNanos()
    {
        return delegate.getReadTimeNanos();

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Avoid pushing the filter on the unsupported type by casting the comparison in SQL so a different code path applies, or filter in an outer query
  2. Drop or rewrite the predicate on the unsupported column type
  3. Upgrade Presto, as newer versions add more type support to FilteringPageSource
  4. If the type should be supported, file/patch the missing case in testNonNullPosition

Example fix

-- before: filter directly on unsupported type
SELECT * FROM t WHERE complex_col = 'x';
-- after: avoid unsupported type dispatch
SELECT * FROM t WHERE CAST(complex_col AS varchar) = 'x';
Defensive patterns

Strategy: try-catch

Validate before calling

Set<TypeFamily> supported = supportedTypesForFilterPushdown();
if (!supported.contains(columnType)) {
    // do not push the filter; keep it in the engine
    return noPushdown(columnType);
}

Type guard

boolean filterPushdownSupported(Type type) {
    return type instanceof BigintType || type instanceof DoubleType || type instanceof BooleanType
        || type instanceof VarcharType || type instanceof DateType || type instanceof TimestampType;
}

Try / catch

try {
    pageSource.filterBlock(block);
} catch (UnsupportedOperationException e) {
    if (e.getMessage().startsWith("Unexpected column type")) {
        // disable filter pushdown for this column and retry with engine-side filtering
    }
    throw e;
}

Prevention

When it happens

Trigger: A predicate filter is pushed down onto a column whose Presto type (e.g. a complex type like map/array/row, or an unhandled type) has no matching branch in testNonNullPosition.

Common situations: Querying a Hive table with an exotic/unsupported column type combined with a WHERE predicate on that column, or a newer type added to the engine but not to this page source's filter dispatch.

Related errors


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