SQLBI is a blog dedicated to building Business Intelligence solutions with SQL Server.

You can follow me on Twitter:

@marcorus
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 www.daxpatterns.com, 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!

## Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using

## 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.

## Comments

## James said:

Marco,

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?

## Marco Russo (SQLBI) said:

James,

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: http://www.sqlbi.com/articles/understanding-dax-query-plans/

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):

http://www.sqlbi.com/consulting/

http://www.sqlbi.com/consulting/

## Ohad Schneider said:

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

COUNTROWS( People ) / 2

with:

COUNTROWS( People ) / (100 / N)

## Marco Russo (SQLBI) said:

Take a look at the percentile definition here:

http://www.daxpatterns.com/statistical-patterns/#percentile23

## Ohad Schneider (MSFT) said:

Sorry, I meant to comment on this blog post:

http://www2.sqlblog.com/blogs/marco_russo/archive/2010/07/20/median-calculation-in-dax.aspx

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

Thanks!

## Ohad Schneider (MSFT) said:

Sorry, I meant to comment on this blog post:

http://www2.sqlblog.com/blogs/marco_russo/archive/2010/07/20/median-calculation-in-dax.aspx

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

Thanks!

## Marco Russo (SQLBI) said:

Ok thanks,

Marco