MX Performance Bot (MXP008): Possible false positive?

0
Good morning,   I’m auditing our solution before a release and taking note of possible performance issues. One thing that has struck me as odd is that, MXP008 gets triggered when a local attribute is on the left side of an add clause, even when the right side of the and references the non-primary key of the associated object. See the example below: The solution according to the bot is the following: Has anyone else brought this up to Mendix and gotten an explanation as to why this is this case?
asked
2 answers
3

Have a look at the resulting SQL query by setting the Connectionbus.Query or .Retrieve on trace level locally and then look at the SQL being created in the two cases.

Then when the statement is different use the database tooling to explain the query to see if there is any significant difference in the expplaination of the query that isn’t obvious from the xpath statement.

Maybe the theoretical idea is that the relation between the objects might be empty and then the query would finish faster by using the associations first, is the only thing I can think of now.

Curious what you find.

answered
4

I did a bit more testing and I think, in part, you are seeing this because you used two sets of square brackets.  If I structure the XPath like this:

The Performance Bot is happy. 

 

Interestingly, if I put the Assignee clause about the WorkflowState clause, the performance Bot throws code MXP015.  So my takeaway is that the Assignee clause is the most expensive part of this query, likely because it is both over an association and uses a token, which requires processing power to translate and is (I am guessing) a separate retrieval action.

 

If you are really curious about the differences in the generated query, you can set log levels for nodes DataStorage_QueryHandling and DataStorage_QueryPlan to Trace to get some insight into the differences in your logs.

answered