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 ,
What you’re seeing comes down to two separate issues. For the first model, the memory error after unpivoting shows that the problem isn’t just VertiPaq CPU but the memory required during processing. While unpivoting reduces columns, it significantly increases row count and cardinality, which can quickly push you over the capacity limit. Instead of unpivoting, a better approach here would be to keep the table narrower without increasing rows, for example splitting the 45 column table into a fact table and a few dimension or attribute tables, and reducing high cardinality columns like text or timestamps.
For the second model, the key clue is that everything works fine until the DirectQuery connection to another semantic model is added. At that point, the dataset becomes a composite model, which introduces cross model dependencies and can lead to Premium capacity queuing. The long executionDelayMs means the refresh is waiting for resources rather than actually processing, even if CPU usage looks low. The reason it works in other reports or production is likely due to differences in capacity load or timing. The most reliable fix is to avoid using DirectQuery to another semantic model in this dataset, either pull the data directly from the source like Snowflake or move that DirectQuery piece into a separate dataset and keep this model import only. If that’s not possible, scheduling during off peak hours can help, but the root issue is architectural rather than performance tuning.
Helper IAnonymous
Hi, thanks for the assist,
I'm now mostly having issues with the second model. For some reason the first just started working on its own.
The second is still behaving very weird.
Like previously mentioned I tried creating a separate file and re-adding one table with all transformations and calculations at a time, + the same incremental refresh settings, and it worked great that way. But then got stuck when adding the connection to the other semantic model.
I've now added the needed table from that model into this report, which is only 240k rows across 7 columns, for one month. And the incremental settings is 12 months archive 14 days refresh. And the only transformations are some filters and removing columns.
So this should be a very fast refresh.
But now yesterday it again took almost hours and failed the second after running for 5 hours!!
Here's the log of the successful run that took forever:
{
"timeStart": "2026-03-12T15:22:45.2800000Z",
"timeEnd": "2026-03-12T17:16:51.5990000Z",
"durationMs": 6846319,
"externalQueryExecutionTimeMs": 158280,
"vertipaqJobCpuTimeMs": 55469,
"mEngineCpuTimeMs": 44234,
"queryProcessingCpuTimeMs": 1156,
"totalCpuTimeMs": 7405500,
"executionDelayMs": 1701765,
"approximatePeakMemConsumptionKB": 12120131,
"tabularConnectionTimeoutMs": 17999000,
"commandType": "Batch",
"discoverType": 129,
"queryDialect": 4,
"refreshParallelism": 6,
"vertipaqTotalRows": 362835436,
"intendedUsage": 2,
"mEnginePeakMemoryKB": 1116324,
"qsoReplicaVersion": 134178094053182000
}
- F003Yum
Anonymous
Here's another execution log from Power BI service, this time there's no delay, but it's still taking two hours despite the snowlake queries and processing is 20 minutes total (this refresh was a full refresh across 12 months)
{
"timeStart": "2026-03-19T09:05:03.7350000Z",
"timeEnd": "2026-03-19T11:07:23.4060000Z",
"durationMs": 7339671,
"externalQueryExecutionTimeMs": 572287,
"vertipaqJobCpuTimeMs": 279266,
"queryProcessingCpuTimeMs": 1750,
"totalCpuTimeMs": 9037406,
"executionDelayMs": 465,
"approximatePeakMemConsumptionKB": 13291915,
"tabularConnectionTimeoutMs": 17999000,
"commandType": "Batch",
"discoverType": 129,
"queryDialect": 4,
"refreshParallelism": 6,
"vertipaqTotalRows": 428585739,
"intendedUsage": 2,
"mEngineCpuTimeMs": 348906,
"mEnginePeakMemoryKB": 4295808
}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.
Hi F003Yum ,
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.