Forum Discussion
Anyone know about MinMaxColumnPositionCallback in DAX Studio server timings?
Solution SageTry to ask this question to Marco Russo and/or Alberto Ferrari. If there's anything to know about it... they are the ultimate source of knowledge about anything DAX.
I know this is over 2 years late, but the SQLBI folks do have some docs on this now, available here:
xmSQL code in VertiPaq - SQLBI Docs
Quote:
MinMaxColumnPositionCallback: Transforms a column value into its position in the list of all values of the column properly sorted. The transformation uses the attribute hierarchy. If the attribute hierarchy is disabled (Available in MDX=False), then this callback cannot be used, and the column must be materialized to the formula engine to find min/max values.Hope this helps whoever searches for this obscure callback type in the future!
I also (sort of) found another fix/cause for this callback.
I'm unfortunately dealing with a DirectQuery model, due to pre-existing architectural choices that are now being re-evaluated. The partiuclar source is Dremio Cloud, which is actually pretty fast and only has a few quirks around DQ, versus the many sources where DQ is terrible for performance. Still not as fast as Import or DirectLake, but changing a whole model mode is not something that can be changed in a few minutes after data load and partitioning strategies are considered. All that said, I have no idea if the below finding would apply in Import mode.
In this particular example, a column, let's call it
'Reporting Scenario'[Scenario]in a Dual-mode table was being evaluated in a SELECTEDVALUE(), and didn't have a sort order column applied. There actually was a sort order column, let's call it
'Reporting Scenario'[Scenario Sort Order]in the same table that was intended to be used, but wasn't applied. Evaluation of this column showed that MinMaxColumnPositionCallback was being evaluated for the column. Applying the sort order column lead to a much simpler xmSQL statement without a MinMaxColumnPositionCallback on re-runs of an otherwise identical query.
Not all such columns where SELECTEDVALUE() would be used will have a meaningful sort order, and again I have no idea if this applies just to DirectQuery, DirectQuery over Dremio, or will hold in future versions of the Power BI engine. I've also rarely seen this callback be a meaningful performance issue in Import models, so unless there's some compelling reason or evidence that this callback is leading to other performance issues in the same measure/query, getting rid of this callback is unlikely to significantly improve report performance. But doesn't hurt to try if time and resources allow.