Execution plan
Stage by stage, what BigQuery did with a query that has run. Row counts in and out, slot time, shuffle volume, and the performance problems Querylab.io recognized in the plan. Open it when a query was slower or costlier than the estimate said it would be.
Execution Stages (5)
12.4M rows
READ AGGREGATE COMPUTE FILTER WRITE
224.6K rows
READ AGGREGATE COMPUTE WRITE
25.0K rows
Opening it
The plan comes from the finished job, so the query has to have run first. Then:
- In the editor’s status bar, the bytes-and-time text after the cost (
0.15 s elapsed, 648.1 MB) gets a dotted underline. Click it. - If the Prism Insights panel is already open, its Execution Plan view updates by itself when the job finishes.
- While a query is still running, the status text is also clickable and shows the stages completed so far.
For a multi-statement script the plan belongs to the statement selected in the results bar; pick another statement and the plan follows. In a notebook, each cell’s status has its own View execution plan.
Reading the plan
The view is ordered so the useful part is at the top.
Summary numbers
Duration, Processed (bytes billed), Cost at the tab’s pricing, Stages, and Cache when the result came from BigQuery’s cache. When the job reports BI Engine statistics, BI Engine Accelerated (with the mode) or BI Engine Not Used (with BigQuery’s reasons) appears here as well.
Performance issues
Querylab.io reads the stage statistics and reports patterns it recognizes. With nothing found, the green card says so. Otherwise each issue has a severity, its impact, the stages involved, and a list of fixes; Optimize with Prism AI hands the plan and the query to the agent with the issues already in context.
| Issue | What the plan showed |
|---|---|
| Partition Pruning Failed | A partitioned table was scanned in full; the filter on the partition column didn’t prune |
| Late Filtering Detected | Filters were applied in a later stage, after bytes had already been processed and shuffled |
| Join Explosion Detected | A join stage wrote many times more rows than it read |
| Data Skew Detected | One worker did a disproportionate share of a stage’s work |
| Sequential Aggregation Bottleneck | An aggregation couldn’t be parallelized and took a large share of the total time |
| Shuffle Spill to Disk | Shuffle data exceeded memory and spilled to disk |
| Slot Starvation Detected | The query waited for slots |
| Insufficient Shuffle Quota | The shuffle quota, not compute, was the limit |
| Query Performance Regression | This run took several times longer than the average of its previous runs |
| BI Engine Not Used | BI Engine acceleration was available but not used |
Execution stages
Collapsed by default. It opens with the Data Flow chart: the source tables with their row counts, then each stage’s operations and the rows it wrote, with the percentage change between stages and its reason: Partition filter, GROUP BY, Filtering, Joining tables. A stage that multiplies rows is marked with the factor.
Below the chart, one card per stage:
| Field | Meaning |
|---|---|
S00: Input + status | BigQuery’s stage name; COMPLETE, RUNNING, or PENDING. The slowest stage carries a BOTTLENECK tag |
| Operations | READ, FILTER, AGGREGATE, JOIN, COMPUTE, SORT, WRITE, … |
| Duration | Wall time and its share of the query, e.g. 341ms (47.5%) |
| Slot-ms | Slot time consumed; this is what a reservation pays for |
| Records Read / Written | Rows in and out of the stage |
| Shuffle | Bytes moved between workers |
| Steps | BigQuery’s own step list: the table and columns read, the filter it applied, the grouping keys |
⌘-click (Ctrl-click on Windows and Linux) a stage card to select the SQL it came from in the editor. A stage whose steps don’t map back to your text (an internal repartition, say) doesn’t react.
When a query has parallel branches (a join reading two tables, a UNION ALL), the stages are drawn as a graph above the cards, left to right by dependency, with the critical path in orange and the bottleneck stage flagged. Straight-line queries skip the graph.