Episode Details

Back to Episodes
Power BI query folding: fix the hidden order of operations slowing your reports

Power BI query folding: fix the hidden order of operations slowing your reports

Season 1 Published 5 months, 2 weeks ago
Description
(00:00:00) The Hidden Execution Order of Power BI Queries
(00:00:48) Power BI's Secret Execution Plan
(00:03:47) Query Folding: Power BI's Optimization Technique
(00:09:00) The Consequences of Folding Failure
(00:13:44) The Three Stages of Query Execution
(00:17:54) Mastering Query Order for Better Performance
(00:21:38) Calibrating Your Curiosity

Power BI query folding: in this episode of M365.fm, Mirko Peters shows why your Power BI reports are slow and inconsistent not because of DAX, but because you misunderstand how Power Query actually orders and executes your steps. He explains the gap between the “Applied Steps” you see on the right and the hidden execution plan underneath—why that list is only a logical story while the engine quietly reshuffles, defers, and sometimes ignores operations based on dependencies and queryfolding. You will learn how this hidden order of operations breaks your mental model: filters you thought were applied early may actually run late, entire branches may never execute, and refresh performance depends far more on folding behavior than on the visual step order.

Mirko dives into the illusion of control inside Power Query. Those nicely named steps look procedural, but M is declarative: it describes what you want, not how or when it runs. He maps this to SQL, where you write SELECT–FROM–WHERE but the database engine internally runs FROM–WHERE–GROUP BY–SELECT–ORDER BY, and shows how Power Query builds a dependency tree and lets the engine optimize execution instead of following your top‑to‑bottom script. You’ll hear how this explains “ghost” behaviour—filters that seem to be ignored, transformations that only sometimes apply, and steps that never execute because nothing downstream ever asks for their results.

The episode then unpacks queryfolding as the hidden optimizer that makes or breaks performance. Mirko explains how folding pushes supported transformations back to the source (SQL Server, Fabric Lakehouse, etc.), so heavy work runs where the data lives instead of on your laptop. He shows how one innocent unsupported step—like a custom text function—can snap folding, forcing Power BI to download huge tables and process everything locally, turning a 20‑second refresh into a 10‑minute nightmare. You will learn how to use “View Native Query,” diagnostics, and careful step design to keep folding alive as long as possible.

You also get a practical performance and modeling playbook based on the article’s core ideas. Mirko outlines how to structure your queries: push filters to the top but in a folding‑friendly way, avoid exotic M functions on large tables, simplify joins, and keep complex logic in views or stored procedures where SQL engines excel. He walks through common failure patterns—broken folding after a custom column, multi‑step transformations that could have been a single folded filter, and overusing Power Query as an ETL engine—and shows how to redesign them so your queries fold cleanly and refresh reliably at scale.

WHAT YOU WILL LEARN
  • Why Power Query’s Applied Steps pane is a logical story, not the real execution order.
  • How M’s declarative nature and the engine’s optimizer decide when and in what order steps actually run.
  • How query folding works, how to see when it breaks, and why one unsupported step can kill performance.
  • How to design folding‑friendly transformations so SQL Server or Fabric does the heavy lifting.
    Listen Now