Skip to content
Module 10 of 1245 min readMixed

Performance — extracts, indexes, the recorder

Why a dashboard is slow: heavy custom SQL, too many marks, blends instead of joins. The Performance Recording feature and how to read it.

83%

Listen along

Read “Performance — extracts, indexes, the recorder” aloud

Plays in your browser using on-device text-to-speech — nothing leaves the page.

Learning objectives

By the end of this module, you should be able to:

  • 01Use the Performance Recording feature to identify slow dashboards
  • 02Apply the four most-effective performance fixes
  • 03Recognise when the bottleneck is Tableau vs the source database

An analyst who ships fast dashboards gets a different reputation from an analyst who ships beautiful but sluggish ones. The good news: performance issues in Tableau follow a small set of patterns. The Performance Recording feature surfaces every query, render, and computation cost; once you can read its output, optimisation becomes mechanical.

Performance Recording

Help → Settings and Performance → Start Performance Recording. Use the dashboard normally for 30 seconds. Stop the recording. A new workbook opens showing every event in time order, with cost in milliseconds. The two columns that matter: 'Event' (what happened) and 'Total time (sec)'. Sort descending by time; the top three events are usually 80% of the lag.

The four most-effective fixes

  • Extract instead of live: typically 5-50x faster for analyst workloads. Schedule the extract refresh based on data-freshness needs.
  • Aggregate the extract: 'Aggregate data for visible dimensions' in extract options pre-rolls up. A million-row extract becomes 10,000 rows; views render instantly.
  • Remove unused fields: 'Hide All Unused Fields' under the Data Source tab. Smaller extract, faster queries.
  • Fix the data model: a star schema with relationships is faster than five joined tables. A flat table is fastest of all (at the cost of duplication).

Custom SQL is almost always the wrong answer

Custom SQL data sources block Tableau's query optimiser. The optimiser can't push filters into a custom SQL block, can't aggregate before fetching, can't combine queries efficiently. If you find yourself writing custom SQL, ask whether a properly modelled data source (in Prep or upstream in the database) would solve the same problem. 90% of the time it would.

When the bottleneck is the source

If you're on a live connection and Performance Recording shows 'Executing Query' taking 10+ seconds, Tableau isn't the bottleneck — the source database is. Options: extract, add indexes on the source tables, pre-aggregate in the source, or use a query cache. The fastest Tableau optimisation is sometimes a Postgres index someone else owns.

Exercise

On any reasonably-sized dashboard, run Performance Recording. Identify the three slowest events. For each, write one sentence on what it is (query, rendering, calc, etc.) and one sentence on what would speed it up. Now apply one fix and re-run the recording. How much faster?

Key takeaways

  • Most slow dashboards are slow because of bad data shape, not bad Tableau.
  • Extracts are faster than live; aggregated extracts faster still.
  • Performance Recording reveals what every action actually costs.
Loading progress…
LeadAfrikPublic Economics Hub