Looker dashboard performance regression: query fanout error slow tiles fix

TL;DR

Find the join or field that fans the query out and remove that multiplication. Fanout happens when a tile query joins a one-to-many relationship and then aggregates, or when a tile pulls fields from many joined views so Looker runs heavier SQL than the visual needs. Simplify the explore for the tile, move the heavy measure to an aggregate table, and confirm tile runtimes in System Activity return to their earlier baseline.

Looker dashboard performance regression: query fanout error slow tiles fix

Use this when

• Dashboard tile runtimes jumped after a LookML change and stayed slow.
• System Activity shows far more rows scanned for the same tiles than before the change.
• The explore gained a new one-to-many join or a new joined view recently.

Not for this skill when

• Every tool against the warehouse slowed at the same time. Investigate the warehouse before the model.
• Only scheduled deliveries are slow while interactive loads are fine. Check the rendering path instead.

Steps

1. Compare current tile runtimes in System Activity with the period before the regression and pick the worst tile. Verify: the slowdown is quantified for at least one named tile
2. Run that tile query in SQL Runner and inspect the generated SQL for fanout patterns, such as a one-to-many join feeding an aggregation. Verify: the plan or row counts show multiplication before aggregation
3. Identify the model change that introduced the fanout, using project history on the explore and its joins. Verify: the change and its timing line up with the regression start
4. Remove the fanout for this use, by splitting the measure into its own explore, using a pre-joined derived table, or building an aggregate table for the tile. Verify: the regenerated SQL scans row counts in line with the source tables
5. Clear the tile cache and time the dashboard load again as a viewer. Verify: tile runtimes are back near the pre regression baseline
6. Add a note or a test query for the explore so the next join change is checked against tile runtimes before merging. Verify: the check exists in the team change process or project tests

Why it happens

Fanout regressions are model changes with delayed, distributed symptoms, so they are often blamed on the warehouse or on data growth. The join graph is the multiplier, and every dashboard on the explore pays it. Reviewing explore changes for new one-to-many joins, and keeping heavy measures on aggregate tables, keeps tile cost proportional to the question being asked.

Looker generates one query per tile, but the cost of that query depends on the join graph it must traverse. Adding a one-to-many join to an explore can multiply rows before aggregation, forcing the database to scan and shuffle far more data, and symmetric aggregates add protective logic that costs more again. A model change that looks small in the project can therefore double every tile runtime on dashboards using that explore, which reads as a sudden performance regression.

Field notes for Looker specifically. The Admin area holds the diagnostic pages that matter here, System Activity for query history and runtimes, the PDT activity page for derived table builds, and the Content Validator under the content management tools. Keep the browser on the same Looker version as the instance when testing, because explore behaviour and error wording shift slightly between monthly releases. Screenshots from viewers are worth collecting with the exact load time, since Looker support and your own history search both work far better from a timestamp than from a description of slowness.

A practical habit for Looker teams is to keep one test user per permission tier and to test every model change as the most restricted tier, not as an admin. Admins bypass access filters, see every field, and hit warm caches, so admin testing systematically hides the failures viewers get. Pair that with a standing explore that lists the twenty slowest tiles across the instance each week, and most dashboard incidents become follow ups on a report the team already reads, instead of surprises reported by executives in a meeting.

Variants and edge cases

Looker dashboard slow after join added fanout explore

The join change phrasing matching the regression trigger.

Looker symmetric aggregates tile runtime doubled fix

The aggregation cost variant for fanned out measures.

Looker System Activity rows scanned tile query regression

The diagnostic variant starting from System Activity evidence.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8igqMNcxHBmMyKj6lkI7g