0
votes

I have a relatively simple DAX query which becomes very slow if I change my SUM(...) into SUMX(...).

The main measure has three versions

  • Version A: CALCULATE(SUM(...))
  • Version B: SUMX(..., IF some_column = constant, other_column)
  • Version C: SUMX(..., IF some_column = variable, other_column)

Finally, I have a FILTER option

DAX Query

Version A is always quick, with or without filter with all work done in storage engine

Version B is pretty quick too, also using the storage engine mostly

Version C is slow IF I add a filter and I don't get why it behaves differently from B, or why the filter has such a bad effect on it.

It uses a variable instead of a constant in the SUMX() and that seems to get resolved by the query engine, hence big delays. In my query context, the variable always evaluates to "Monthly".

In particular it becomes very slow if I add a filter to my query.

Can someone explains why B & C behave so differently? How could I get B's performance with a variable instead of the constant? Could I use a filter somehow to avoid the Query Engine kicking in?

I join screenshots of the Version C queries that use a lot of query engine when I add the filter

Without filter -> Storage Engine Without filter (storage engine)

With filter (Query Engine kicks in) With filter (Query Engine kicks in)


Adding the tables relationship as a diagram Tables relations

1
can you post your data model diagram that shows all relevant tables and their relations?RADO
I just discovered that I can apparently solve my speed issue by replacing my SUMX(?, IF(...)) by a CALCULATE(SUM(), FILTER) as this is entirely resoved by the Storage engine... CALCULATE(SUM('Fact'[RAW_SALES_UNIT]), 'Fact'[FREQUENCY] == FrequencyOption) But I would still like to understand the difference in behaviour between Version B & C...Eric Mamet
I've run into similar issues. It seems like the internal optimization engine needs improvement.Alexis Olson
@RADO I don't see how to attach files...Eric Mamet
I think the issue is caused by bidirectional relations - there is no reason to have them in this model. Try to change them to the normal 1 to many and see if there is a difference. In general, avoid bi-directional relations at all costs.RADO

1 Answers

0
votes

In this particular case, it looks like I can solve my performance problem by "rephrasing" using CALCULATE() and a simple filter.

CALCULATE() option runs far better

I have no explanation for the major speed difference between Versions B & C but version D performs very well with or without the filter