Forum Discussion
Visual initial loading time retrieval
- 19 days ago
Hi CU08101843,
The fact that the visuals load in about 3 seconds when the relationship is disabled is a very strong clue.
I would not focus on the 9 MB PBIX size here. In DirectQuery, the important part is the SQL Power BI generates against the source.
With the relationship active, Power BI may need to join the two tables for each visual, and that join can become expensive depending on:
relationship cardinality join key data type indexes filter direction source table sizeMicrosoft’s DirectQuery guidance specifically recommends checking the generated source query and optimizing the relationship/join columns.
I would start with Performance Analyzer and copy the query for one of the slow visuals.
Then run that query directly against the database and check:
- execution plan
- indexes on both relationship keys
- whether the join columns use the same data type
- whether casts or calculated expressions are being introduced
- whether the relationship is bidirectional unnecessarily
One setting worth testing is Assume referential integrity.Microsoft documents that, when the data satisfies the requirements, Power BI can use an INNER JOIN instead of an OUTER JOIN, which can make DirectQuery joins more efficient.
The requirements are important though:
- no null/blank values on the many-side key
- every many-side key must have a matching value on the one side
Microsoft explains that behavior in the Assume referential integrity documentation.So my troubleshooting order would be:
Performance Analyzer -> inspect generated SQL -> validate indexes and join keys -> test Assume referential integrity if the data allows it -> review relationship direction/cardinalityIf the same SQL query still takes close to a minute when run directly against the database, then the main fix will be at the source/index/query-plan level rather than in DAX.
Getting every DirectQuery visual under 2 seconds may not always be realistic, but a jump from 3 seconds to 60 seconds because of one relationship is definitely something I would investigate at the generated join first.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Hi CU08101843,
The fact that the visuals load in about 3 seconds when the relationship is disabled is a very strong clue.
I would not focus on the 9 MB PBIX size here. In DirectQuery, the important part is the SQL Power BI generates against the source.
With the relationship active, Power BI may need to join the two tables for each visual, and that join can become expensive depending on:
relationship cardinality
join key data type
indexes
filter direction
source table sizeMicrosoft’s DirectQuery guidance specifically recommends checking the generated source query and optimizing the relationship/join columns.
I would start with Performance Analyzer and copy the query for one of the slow visuals.
Then run that query directly against the database and check:
- execution plan
- indexes on both relationship keys
- whether the join columns use the same data type
- whether casts or calculated expressions are being introduced
- whether the relationship is bidirectional unnecessarily
One setting worth testing is Assume referential integrity.
Microsoft documents that, when the data satisfies the requirements, Power BI can use an INNER JOIN instead of an OUTER JOIN, which can make DirectQuery joins more efficient.
The requirements are important though:
- no null/blank values on the many-side key
- every many-side key must have a matching value on the one side
Microsoft explains that behavior in the Assume referential integrity documentation.
So my troubleshooting order would be:
Performance Analyzer
-> inspect generated SQL
-> validate indexes and join keys
-> test Assume referential integrity if the data allows it
-> review relationship direction/cardinalityIf the same SQL query still takes close to a minute when run directly against the database, then the main fix will be at the source/index/query-plan level rather than in DAX.
Getting every DirectQuery visual under 2 seconds may not always be realistic, but a jump from 3 seconds to 60 seconds because of one relationship is definitely something I would investigate at the generated join first.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.