Press "Enter" to skip to content

Day: February 17, 2026

Measuring Page Load Times in Power BI

Published 2026-02-17 by Kevin Feasel

Chris Webb breaks out the stopwatch:

If you’re performance tuning a Power BI report the most important thing you need to measure – and the thing your users certainly care about most – is how long it takes for a report page to load. Yet this isn’t something that is available anywhere in Power BI Desktop or in the Service (though you can use browser dev tools to do this) and developers often concentrate on tuning just the individual DAX queries generated by the report instead. Usually that’s all you need to do but running multiple DAX queries concurrently can affect the performance of each one, and there are other factors (for example geocoding in map visuals or displaying images) that affect report performance so if you do not look at overall page render times then you might miss them. In this post I’ll show you how you can measure report page load times, and the times taken for other forms of report interaction, using Performance Analyzer in the Service and Power Query.

Read on to see how.

Leave a Comment

License Types now Workspace Types in Microsoft Fabric

Published 2026-02-17 by Kevin Feasel

Nicky van Vreonhoven notices a change in language:

Just a quick post because I noticed a change in the Fabric UI, specifically in the Workspace settings.

I am working on a demo for my Power BI Gebruikersdagen session, and wanted to switch a workspace to Fabric capacity. I noticed that the setting License type has changed, and is now called Workspace type.

Read on to see where this has changed and a few more notes from Nicky.

Leave a Comment

Snapshot Reporting in Microsoft Fabric via Fabric Pipelines

Published 2026-02-17 by Kevin Feasel

Kenneth Omorodion builds a Dataflows Gen2 pipeline:

In a previous tip, I described how we can implement snapshot reporting using Microsoft Fabric Dataflow Gen2. In this article, I will describe how to achieve the same using Microsoft Fabric Pipelines. I previously described how important snapshot reporting can be in Business Intelligence reporting. Some reasons why developers/engineers might prefer to leverage a Fabric pipeline instead of a Dataflow Gen 2 include considerations around cost efficiency and data volumes.

My strong preference is still to do this in code (notebooks, Spark jobs), but at least Dataflows Gen2 aren’t literally 100x slower than the alternatives anymore.

Leave a Comment

Memory-Optimized Storage Structures in SQL Server

Published 2026-02-17 by Kevin Feasel

Hugo Kornelis digs into another storage structure:

After discussing traditional on-disk rowstore storage in part 1 and columnstores in part 2, it is now time to turn our eye towards memory-optimized storage structures in SQL Server.

Memory-optimized storage was introduced in SQL Server 2014, as part of a project that was codenamed “Hekaton” and later renamed to in-memory OLTP. Whereas columnstore indexes were specifically targeted towards large scale analytical work, Hekaton and memory-optimized tables are specifically geared towards high volume OLTP workloads. By fully eliminating locks and latches, and using precompiled machine code where possible, the processing time of transactions is significantly reduced, allowing for throughput numbers that were previously impossible to achieve.

Read on to learn much more about how SQL Server manages memory-optimized data and the types of operations that are permissible on this internal storage.

Leave a Comment

Running PostgreSQL Tasks as Background Operations

Published 2026-02-17 by Kevin Feasel

Vibhor Kumar describes a PostgreSQL extension:

That’s the promise of pg_background: execute SQL asynchronously in background worker processes inside PostgreSQL, so your client session can move on—while the work runs in its own transaction. 

It’s a deceptively simple superpower:

  • Kick off a long-running query (or maintenance) without holding the client connection open
  • Run “autonomous transaction”-style side effects (commit/rollback independent of the caller)
  • Monitor, wait, detach, or cancel explicitly
  • Keep the operational model “Postgres-native” instead of adding another job system  

Read on to learn more about it, including tips on how to use it and some examples of when you might want to use it.

Leave a Comment

Occasional Query Failures on a Small Table

Published 2026-02-17 by Kevin Feasel

Paul Randal troubleshoots an issue:

The table in question only had a few million rows of data in it, with a maximum row size of 60 bytes, and the query usually ran in a few seconds, but occasionally the query would ‘hang’ and would either be killed or take tens of minutes to run. Troubleshooting instrumentation when the issue happened showed no out-of-the-ordinary waits occurring, no pressure on the server, and the query plan generated when the query took a long time was essentially the same.

The only thing noticeable was that when the problem occurred, a column statistics update happened as part of query compilation, but with such a tiny table, how could that be the root cause of the issue? The calculated disk space for the row size and count worked out to be about 250MB, but with a statistics sample rate of only 4%, extended events showed an auto_stats event taking close to an hour!

Read on to learn the cause. I will admit that I did not get this one correct when I guessed what the cause could be.

Leave a Comment