Forum Discussion
Helper ISuper long refresh times despite incremental refresh
Anonymous Hi!
After some more experimenting and remaking all the calculated columns, reinstalling power bi etc it now works. I also noticed during on of the tests where a refresh took 2 hours, that it completed with a warning, and that warning was referencing a table that wasn't even loaded into the model.
So seems that perhaps some metadata or other stuff had been slightly corrupted? Either way now after rebuild it's only taking 3 minutes to refresh, with the idenditcal aggregation etc...
Hi F003Yum ,
Based on what you’ve shared, the behavior aligns with documented Power BI behavior. For the first model, the memory error after unpivoting is expected, as increasing row count and cardinality can significantly raise memory usage during VertiPaq processing, even if columns are reduced. In such cases, keeping the model optimized with a star schema approach and reducing high cardinality columns is generally more effective. For the second model, adding the DirectQuery connection to another semantic model creates a composite model, which can introduce additional processing overhead and dependencies that impact refresh performance.
In addition, Premium capacity uses workload management and capacity limits, meaning refresh operations can be queued or delayed even when CPU usage appears normal, which is reflected in the executionDelayMs values you’re seeing. It’s also important to note that incremental refresh reduces the amount of data retrieved from the source, but partitions still need to be processed in memory, so overall refresh duration can still be affected by model size and design. Overall, this behavior is consistent with how Premium capacity and composite models operate, so focusing on model optimization and being mindful of composite model overhead should help improve performance.
Helper IAnonymous
Hi!
Thanks for the reply and sorry for my delayed response.
Regarding the second model I'm still encountering the same issues even when having removed the direct query and instead import the table from our database instead.
The execution logs from previos posts are with that done.
When doing some more testing this morning I ran into an issue where it has previously worked during testing.
It's a table where we have rows aggregated for every 15 minutes. And in power query I do an group by / aggregation up to every hour instead.
Previously I've tested adding incremental refresh one table at a time and uploading into our test workspace (in a brand new report file) and there it has worked with incremental refresh on all tables.
But now this morning it failed with the above mentioned group by.
This report uses the same fact table three times,
One without transformations and is the default table with 15 minute intervals, and rows for Column B, One column A can have multiple rows for the same 15 minute interval, with ColumnB being different.
One version where we group by to get per hour and with all from "ColumnB" toghether. This group by works fine with incremental refresh.
And one final version where we group by to get per hour. And this one is now failing, but it previously worked...
Example of default table, but then more rows for each quarter of the day etc
| Name | B | C | Value1 | Value2 | Hour |
| A | 2026-03-23 12:15:00 | 1 | 1 | 10 | 12 |
| A | 2026-03-23 12:15:00 | 2 | 2 | 20 | 12 |
| A | 2026-03-23 12:15:00 | 3 | 3 | 30 | 12 |
| B | 2026-03-23 12:15:00 | 1 | 656 | 576 | 12 |
After the third group by:
| Name | B | Value1 | Value2 | Hour |
| A | 2026-03-23 | 6 | 60 | 12 |
| B | 2026-03-23 | 656 | 576 | 12 |
Hi F003Yum ,
Thank you for the detailed update, it really helps clarify the issue. From what you’ve described, it seems the problem is likely related to query folding at the group by step, rather than capacity or composite model issues. Incremental refresh depends on Power BI pushing date filters to the source, but certain group by patterns or changes in column order or data types can prevent this. When folding breaks, Power BI pulls in more data and aggregates locally, which explains the failures and inconsistent behavior you’re experiencing, and why one grouped version works while another does not. Using the same fact table multiple times can also increase the load, as each reference might be evaluated separately. The main thing to check is whether folding is maintained in the failing query. If not, performing hourly aggregation closer to the source usually makes incremental refresh more reliable in these cases.
Hi F003Yum ,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you