Skip to main content
External Table queries read Parquet from object storage at query time instead of a local segment, so the fastest path to low latency is indexes and caching — not more compute. Three changes cover almost every slow-query case:

​
1. Add indexes for your filter and group-by columns

Without an index, every query does a full remote scan. A range index on time/numeric columns and an inverted index on the low-cardinality columns you filter on most will fix the majority of slow queries. → Supported Indexes — what’s supported, how to add one, and why every column starts out RAW (no dictionary).

​
2. Turn on caching and preload

The first read of any column pays the cost of fetching it from object storage; caching keeps that data local so repeat queries don’t pay it again. Preload goes further, pulling small hot indexes (bloom filters, dictionaries) into memory eagerly at segment load instead of on first query. → Data and Index Caching — how the Parquet data cache, index cache, and footer cache work. → Best Practices and Configs — Caching and index pinning — which indexes to pin vs. leave to the cache.

​
3. Protect large scans from OOM

Tables that get heavy aggregations or wide scans can push a server’s heap to its limit. Server-side per-query memory accounting kills the heaviest query instead of crashing the server when that happens. → Best Practices and Configs — Query OOM protection

​
Still slow?

If you’ve done all three and a specific query is still slow or times out, check Troubleshooting — Query times out or returns “servers not responded” for the full diagnostic order, including under-provisioned servers and derived-column group-bys that defeat pruning.