THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

SQLBI - Marco Russo

Please visit the same blog at - comments are now disabled here but you can comment on the new blog (all blog posts available here are available there, too).
You can follow me on Twitter: @marcorus

Common Statistical #DAX Patterns for #powerpivot and #tabular

DAX includes several statistical functions, such as average, variance, and standard deviation. Other common algorithms require some DAX code and we published an article about common Statistical Patterns on, including:

I think that Median and Percentile implementation are the most interesting patterns, because performance might be very different depending on the implementation. I am sure that a native implementation in DAX of such algorithms would be much better, but in the meantime you can just copy and paste the formulas presented in the article!

Published Thursday, March 20, 2014 2:43 PM by Marco Russo (SQLBI)
Filed under: , , ,



James said:


I'm using both the median and percentile patterns, on a fairly small dataset (approx 200000 rows in fact table, then calculating the percentile by month, and potentially further splitting by area.

The performance is really bad, especially in PowerView.  In most cases, I wait up to 30 seconds for the results, even though the entire model is in memory.

Note we're showing about 15 of these calculations in the results, i.e. a matrix of percentiles and medians for each month.

Do you have any suggestions on optimizing the pattern?  You mention that the performance could be affected by implementation.

I'm in the process of testing 'pre-calculating' all these intensive measures as calculated columns and using a switch, but it seems there must be a better way?

September 16, 2014 5:44 AM

Marco Russo (SQLBI) said:


I know that performance might suffer because of the implementation that is required in DAX. One of the possible optimizations is "pre-calculating" measures as calculated columns - if you can define such a column using the cardinality of tables you already have.

Other techniques might depend on the specific needs of your measures and/or on the characteristics of the data model. We usually do that by examining the performance using the profiler and finding possible alternative models/measures/calculation techniques that might optimize query time for the specific data model.

You can find an introduction to DAX Query Plans here:

We are also available to provide consultancy, even if in this specific case you might already have a good solution in mind (consolidating data in calculated columns, if model permits):

September 16, 2014 7:01 AM

Ohad Schneider said:

I guess this could easily be expanded into the Nth percentile by replacing

COUNTROWS( People ) / 2


COUNTROWS( People ) / (100 / N)

March 15, 2015 1:50 PM

Marco Russo (SQLBI) said:

Take a look at the percentile definition here:

March 21, 2015 3:23 AM

Ohad Schneider (MSFT) said:

Sorry, I meant to comment on this blog post:

However I can see now that this post is much more updated.


March 22, 2015 6:29 AM

Ohad Schneider (MSFT) said:

Sorry, I meant to comment on this blog post:

However I can see now that this post is much more updated.


March 22, 2015 6:29 AM

Marco Russo (SQLBI) said:

Ok thanks,


March 22, 2015 6:59 AM
New Comments to this post are disabled

About Marco Russo (SQLBI)

Marco Russo is a consultant, writer and trainer specialized in Business Intelligence with Microsoft technologies. He runs the SQLBI.COM website, which is dedicated to distribute resources useful for BI developers, like Integration Services components, Analysis Services models, tools, technical information and so on. Marco is certified as MCT, MCDBA, MCSD.NET, MCSA, MCSE+I.

This Blog



Privacy Statement