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
- 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
- Drop or rewrite the predicate on the unsupported column type
- Upgrade Presto, as newer versions add more type support to FilteringPageSource
- 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
- Only push down predicates on types known to be supported by FilteringPageSource
- Check the Type before building the filter
- Test complex-type filters without pushdown
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
- Unsupported column type:
- unknown java type
- NOT_SUPPORTED
- Unsupported type:
- Unknown object inspector category:
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/a07d974c97ea9287.
Report an issue: GitHub.