PERFORMANCE ISSUES IN PAGINTED REPORT BUILDER

Hi swatig2904​
Three changes are likely to have the biggest impact, in this order:

1) Push the filters into the query:
Map each report parameter to a dataset/query parameter, rather than applying the filter after the data is retrieved. With 24 filters this can make a significant difference, because the query returns only the rows you need instead of retrieving all 1.5M first.

2) Apply the D1, D2 and D3 filters directly to the fact table.
All three date columns relate to the same dim_date, and only one relationship between two tables can be active at a time. Microsoft's guidance is that when a report needs to filter by different roles at the same time, the model needs a separate date table for each role. Filtering the fact table's own columns avoids needing that.

EVALUATE SUMMARIZECOLUMNS( 'Fact'[ColA], 'Fact'[ColB], KEEPFILTERS( FILTER( ALL('Fact'[D1]), 'Fact'[D1] >= @StartD1 && 'Fact'[D1] <= @EndD1 ) ), KEEPFILTERS( FILTER( ALL('Fact'[D2]), 'Fact'[D2] >= @StartD2 && 'Fact'[D2] <= @EndD2 ) ), KEEPFILTERS( FILTER( ALL('Fact'[D3]), 'Fact'[D3] >= @StartD3 && 'Fact'[D3] <= @EndD3 ) ) )

3) Create a report-specific view.
Keeping the transformation logic in Databricks is reasonable. However, if the report doesn't actually display all 80+ columns, create a narrower view containing only the ones it needs. I would also make the date parameters mandatory, or give them a sensible default range, so the report doesn't run against the full 1.5M rows unnecessarily.

A couple of things are also worth checking.

First, identify where the time is being spent, query execution, data retrieval, report processing, or rendering. That will tell you which change will have the biggest effect before you alter any modelling.

Second, if the semantic model is DirectQuery, report queries against it have a fixed 10-minute timeout. For queries that run longer than that, the documented approach is to use the model's XMLA Read/Write endpoint as the report data source instead.

Regarding the flattened view, I wouldn't rebuild the model into a star schema solely to address this. The bigger concern is the volume being requested: 1.5M rows × 80+ columns.

Semantic models are designed to summarise large volumes quickly, but the guidance is explicit that they aren't suited to reports that need to retrieve very large volumes of data — in excess of about 10,000 rows. Relational sources are the documented choice for result sets that size, so at 1.5M rows you're well beyond what this path is built for.

If the actual requirement is to retrieve all 1.5M rows, I would extract the data directly from Databricks rather than using the semantic model as a bulk-data source.

References
https://learn.microsoft.com/power-bi/guidance/report-paginated-data-retrieval
https://learn.microsoft.com/power-bi/paginated-reports/paginated-reports-data-sources
https://learn.microsoft.com/power-bi/guidance/relationships-active-inactive

Thanks,
C Srikanth
Community Support Team