Data modelling and DAX
An optimisation has shipped in the Power BI semantic model engine that cuts the time spent preparing a query that uses calculation groups. It happens before any data is read, so it will not speed up your scans. Some models will barely notice. Models with several calculation groups that reference each other could see a lot. Here is what was happening, why it was written that way, and how to work out which camp you are in.
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
