Forum Discussion
Helper ISuper long refresh times despite incremental refresh
Hi!
I'm having an issue with two models that I'm uploading into our premium capacity workspace with their refreshes taking way longer than they should.
The first model is set to 24 months archive + 14 days incremental refresh. But it takes way to long to refresh it's 14 day incremental.
those 14 days would be around 450K rows across 45ish columns (lots of columns even after removing a whole bunch)
Refreshing one month 940k rows takes 23 seconds. But when refreshing in the service it takes over 20 minutes
When I check the query history in our snowflake environment I can see that it is properly querying only for those 14 days. So query folding seems to be happening as far as I can tell.
These are the execution details in power bi service:
{ "timeStart": "2026-03-11T07:55:44.0460000Z", "timeEnd": "2026-03-11T08:14:13.7200000Z", "durationMs": 1109674, "externalQueryExecutionTimeMs": 84039, "vertipaqJobCpuTimeMs": 1386031, "queryProcessingCpuTimeMs": 9563, "totalCpuTimeMs": 2366141, "executionDelayMs": 294, "approximatePeakMemConsumptionKB": 15487240, "tabularConnectionTimeoutMs": 17999000, "commandType": "Batch", "discoverType": 129, "queryDialect": 4, "refreshParallelism": 6, "vertipaqTotalRows": 3566793, "intendedUsage": 2, "mEngineCpuTimeMs": 142625, "mEnginePeakMemoryKB": 2024484 }
Vertipaq CPU seems to be the main consuming part here. Which I don't understand?
There are also no transformations at all in powerquery, it's just a date/time filter for the rangestart/rangeend parameters and then selecting the columns needed.
Also, for both models the snowflake queries are very quick. All less than 0.5 sec with some at most 2 sec
Any ideas on what's going on or how to troubleshoot this further?
Thanks!
I then have another issue with a table in another model that is set to 12 months archive, 14 days incremental.
One month in this table is around 3 million rows, so we can assume that 14 days is around 1.5 million rows across 11 columns.
This table is then also loaded, but aggregated via group by in power query (we need both for the report) into only 254k rows for 1 month. Edit: This aggregated table is not referencing the first table.
But this refresh is taking almost TWO HOURS, and again. When I check snowflakes query history I still only see queries for those 14 days that should be refreshed. So seems like the incremental query folding is working?
When I check the execution details in power bi service it says this:
{ "timeStart": "2026-03-11T10:35:30.4850000Z", "timeEnd": "2026-03-11T12:23:26.9100000Z", "durationMs": 6476425, "externalQueryExecutionTimeMs": 166693, "vertipaqJobCpuTimeMs": 135484, "mEngineCpuTimeMs": 87156, "queryProcessingCpuTimeMs": 734, "totalCpuTimeMs": 7364578, "executionDelayMs": 6599793, "approximatePeakMemConsumptionKB": 12280456, "mEnginePeakMemoryKB": 1621644, "tabularConnectionTimeoutMs": 17999000, "commandType": "Batch", "discoverType": 129, "queryDialect": 4, "refreshParallelism": 6, "vertipaqTotalRows": 377166978, "intendedUsage": 2, "qsoReplicaVersion": 134177054007085840 }
And here we can see that the Execution Delay is 110 minutes, which is super weird, because when I checked the compute history for our server it was around 40-50%, so I don't understand what it is waiting for?
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...
16 Replies
- Juan-Power-bi
Super User
Good follow-up questions!
Model 1 — pivoting: It depends on what "pivot" means in context. If you mean transposing wide columns into rows (unpivoting), that would actually help a lot — fewer columns means less VertipAQ encoding work, and narrow tall tables compress far better than wide flat ones. If you mean something else, share more detail. But as a general rule: reducing from 45 columns to something leaner (even 20-25) would noticeably cut that VertipAQ CPU time.
Model 2 — the execution delay: You're right that the actual processing in the logs is trivial — the real work takes maybe 3-4 minutes total. The 110-minute wait is entirely executionDelayMs, which is capacity queuing, not your transformation. The transformation itself isn't the problem at all.
The reason capacity queuing happens even at 40-50% compute is that Premium capacity throttling isn't purely CPU-based — it uses a CU (Capacity Unit) smoothing algorithm that averages usage over a 24-hour rolling window. If earlier jobs consumed a burst of CUs, your capacity can be in a throttled state even while the instantaneous CPU looks fine. Check the Fabric Capacity Metrics app and look at the CU smoothing chart around the time of the refresh — you'll likely see the throttling period clearly there, even if the raw compute graph looks okay.
Short-term fix: schedule model 2's refresh during off-peak hours when the CU bucket has recovered.
F003YumThanks again,
Yes that's what I meantwith pivoting, it did however having the effect of running out of memory when trying to refresh the model:
Data source errorResource Governance: This operation was canceled because there wasn't enough memory to finish running it. Either reduce the memory footprint of your dataset by doing things such as limiting the amount of imported data, or if using Power BI Premium, increase the memory of the Premium capacity where this dataset is hosted. More details: consumed memory 24880 MB, memory limit 24775 MB, database size before command execution 824 MB
For model 2, I did try and recreate the model one table at a time and at every step it worked perfectly and eventually the whole model was uploaded in and it all worked great, the only thing that wasn't added to the model was the measures. Other than that the model was exactly the same. Except for the final step, when I added a direct query to one of our large semantic models that feeds a couple of other reports. Then it stopped refreshing and we encounterd the previously mentioned super long execution delay.
Which is very weird, since it's working with a bunch of other reports?
Also weird is that the version of this report that is in the production workspace also has this connection and there it works?
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.
Hi F003Yum ,
I would take a moment to thank Juan-Power-bi , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
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
- Juan-Power-bi
Great detail in those execution logs
Maybe you can try this :
Stagger your refreshes so the two models don't run at the same time
Check the Fabric Capacity Metrics app to see if you're consistently hitting capacity limits during the refresh window
For model 1, trim columns and consider whether the 45-column wide table could be split into a fact + narrow attribute table
For model 2, check if the aggregated table really needs to be in the same semantic model or could be pre-aggregated upstream in a dataflow- F003Yum
Hi!
Thanks for the reply!
For model 1: Would it help to pivot the table?
For model 2: I guess we could pre-aggregate it in snowflake but I'm confused as to why it's needed based on the log details.
With my limited knowledge it seems like that transformation isn't taking that long when reading the log details?
When I check the compute graph it's not over 40-50% load during the refresh, so I don't think that's the culprit
