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.
Different models are better at different jobs. Use a premium reasoning model for planning and design. Once the plan is locked, switch to a faster, cheaper model to execute it. Stop sending the senior partner to file the paperwork.
