Data modelling and DAX
DISTINCTCOUNT over a high cardinality transaction ID is one of the most expensive things you can ask the storage engine to do. If you understand which of your dimensions have a functional dependency on that ID, you can answer a large share of your queries with a plain COUNTROWS instead, and shrink the work for the ones that are left.
Row-level security quietly switches strategies once a table gets big enough. A recent default change moves that line from 128K rows to 512K, and the reason it is not 2 million is a nice bit of engineering.
When writing DAX queries, performance tuning often comes down to small design decisions that have big consequences. One such decision is whether to include Primary Key columns from Dimension tables in your SUMMARIZECOLUMNS statements. This is particularly important when those Dimension tables use DUAL or IMPORT storage modes. This article explains why doing so can … Continue reading The Impact of Primary Keys on DAX Query Performance in Power BI
If you’ve been working with Direct Lake in Microsoft Fabric, you’ll know its magic resides in its ability to quickly load data. It loads data into semantic models from OneLake when needed. This feature eliminates the overhead of importing. But until recently, the first query on a cold cache might feel sluggish. Why? One reason … Continue reading Direct Lake Performance Gets a Boost: Faster Join Index Creation
