MSHGQM - Optimizing DAX with Marco Russo!

Description:
The long awaited CALCULATE, No CALCULATE cage fight is here! Not really, Marco Russo and I amicable talk about his new book, Optimizing DAX, 2nd Edition. But yes, we do talk about CALCULATE/No CALCULATE so enjoy!

Books!

[DataMadScience]

Really interesting discussion - thanks to both Marco and Greg for their insights.

[carltonseymour]

Spent one of my best early morning hours listening to this incredible respectful conversation between two awesome human beings. As always Marco has an incredible and fluid way of explaining things that he has experienced over years and years. Thank you Greg. Thank you Marco

[mwaltercpa]

Really a great discussion. Working through the optimize book has been very eye opening for me. Calculate is indeed everywhere, seen or unseen, however I do have a new appreciation for SUMX and knowing when it will likely be the more performant pattern. Thanks to you both!

[tamerjuma]

Two shining stars ⭐️ ⭐️
Such amazing informative interview! Thank you Greg for having Marco to take us through this open minded discussion.

[DeronHuskey]

There were not enough folding chairs and over-the-top rope suplexes for my taste.

Other than that, excellent discussion.

I watched the first version of the Optimizing Dax video series a couple of years ago and am almost half-way through the second.

As you said, it goes into a lot of detail and I've watched several of the chapters several times.

It's a complex topic, similar to understanding Oracle and SQL Server query plans, which after almost 60 years man and boy, I still have trouble wrapping my head around.

I equate the no-calc method to how I write SQL...I build a CTE (or several) that summarizes data and then join them to my presentation query.

Thanks for getting the interview and sharing it with us.

[frizz-vbct]

This is super interesting! Thanks for sharing!

Regarding the discussion about snowflake vs. star schema in Power BI (28:30-31:05):

Isn't the snowflake schema's requirement for relationships between each hierarchical table (e.g. product < subcategory < category) a potential performance issue? Because calculations will need to traverse these relationships.

And thus one of the main reasons (on the physical layer) to use star schema instead of snowflake schema is so that Power BI doesn't have to traverse such relationships?


In addition to the user-friendliness (on the logical layer) of having the whole hierarchy represented as columns in a single dimension table.

[downunderdax]

Great discussion.
I think I need to watch it again to really understand it all, and then I will probably just realize that I only understand that I really don't understand it all.
The one topic that I was hoping would come out in the "Cage Fight" was the issue around DAX totals.
Maybe that can be your next ring match 😉

[edavidzh]

Thank you for the great video. The only reasons I use Date table in Monthly reports is ability use calendar range slicer...I wish there would be MonthYear from to MonthYear slicer

[richardmartin]

This was awesome. Any chance you can have more guests?

[MDevion]

The whole discussion attribute on fact/dimension is an old discussion. If the granularity of a dimension is almost the same as a fact, it probably will only be used for 1 fact. Therefore its a fact dimension and the attribute should reside on the fact table as that attribute is most likely not shared with other facts.

Its the same in MD, its not really something new...