Reading the query profile

What it is

Query History lists every statement run on a SQL warehouse, with duration, user, and status. Opening one and clicking See query profile shows a query profile: a directed graph of the operators the engine actually executed — scans, joins, aggregations, shuffles — each annotated with its own metrics. It is the SQL-warehouse equivalent of the Spark UI’s stages and tasks (see Spark UI: skew, shuffle, and spill), but built around the operators a SQL statement compiles into rather than raw Spark stages.

Why it exists

A query duration tells you that something is slow, not what. The profile graph attributes time, rows, and bytes to each individual operator, so instead of guessing you can point at the one join or scan responsible for most of the runtime and fix that specific thing.

How it works

The graph

The profile renders the query plan as a DAG: each node is an operator, edges show data flowing between them. Clicking a node opens its detailed metrics; a side panel also summarizes the three tabs Details (overall stats), Top operators (the most expensive ones), and Query text.

The metrics that matter

Spotting a missing filter

If a scan’s rows read is close to the table’s full row count while rows returned is tiny, the predicate isn’t being pushed down or pruning isn’t happening — check that the filter is on a clustering or partition column, and that it isn’t wrapped in a function that defeats pruning (WHERE YEAR(order_date) = 2026 instead of a direct range on order_date).

Spotting a bad join

A join with a much larger rows out than the sum of its inputs is an exploding join: a many-to-many match on a key that should be unique on at least one side. Heavy shuffle and spill on a join usually mean the smaller side didn’t get broadcast, or one join key is heavily skewed.

Photon

Photon-executed operators report their own metrics; some non-Photon operators are grouped together and share combined metrics rather than being broken out individually, so a profile from a Photon-enabled warehouse can look coarser in places than a fully vectorized breakdown.

Example

Two versions of the same aggregation — compare their profiles rather than their SQL:

-- 1) No filter: full scan, rows read ≈ table size, no pruning
SELECT customer_id, SUM(amount) AS total
FROM sales.gold.orders
GROUP BY customer_id;

-- 2) Filtered on the clustering column: files pruned, rows read shrinks
SELECT customer_id, SUM(amount) AS total
FROM sales.gold.orders
WHERE order_date >= DATE'2026-01-01'
GROUP BY customer_id;

In the first profile, the scan operator shows most files read and no pruning; in the second, the same scan shows a high pruning percentage and a much smaller bytes read, with less downstream work for the aggregation.

Common mistakes

• Looking only at total query duration instead of which operator owns most of the time.
• Ignoring the gap between rows read and rows returned — the clearest sign of a missing or ineffective filter.
• Not checking spill to disk, then concluding the query is “just slow” instead of undersized or skewed.
• Treating queueing time (waiting for a free cluster, see Sizing a SQL warehouse) as part of the query’s own execution time.
• Assuming Photon’s grouped metrics mean an operator did nothing, when it’s simply reported together with neighboring steps.