Forum Discussion
Super long refresh times despite incremental refresh
- 5 months ago
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...
Anonymous
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
}
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
}
- Anonymous5 months agoNot applicable
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.
- Anonymous5 months agoNot applicable
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.- F003Yum5 months ago
Helper I
Anonymous
Hi sorry for the late reply, When I check in our SnowFlake Query history, it does look like it's only sending queries for the intervals set up in the incremental settings. But there are some extra queries like the following that appear almost more often than the real query
SHOW PRIMARY KEYS IN TABLE "DB"."Schema"."Table"
SHOW COLUMNS IN TABLE "DB"."Schema"."Table"
Here's an anonymised version of the query that messes up the load time: (then as previously mentioned there's a small number of simple calcualted columns as well)
let Source = Snowflake.Databases( "your_account.region.azure.snowflakecomputing.com", "DATA_SOURCE", [Implementation = "2.0"] ), TargetDatabase = Source{[Name = "TARGET_DB", Kind = "Database"]}[Data], TargetSchema = TargetDatabase{[Name = "TARGET_SCHEMA", Kind = "Schema"]}[Data], FactTable = TargetSchema{[Name = "FACT_TABLE", Kind = "Table"]}[Data], #"Filtered on Date Range" = Table.SelectRows( FactTable, each [TimePeriod] >= RangeStart and [TimePeriod] < RangeEnd ), #"Selected Columns" = Table.SelectColumns( #"Filtered on Date Range", { "EntityID", "Date", "Hour", "TimePeriod", "DeviceID", "Measure1", "Measure2", "Measure3", "Measure4" } ), #"Grouped Rows" = Table.Group( #"Selected Columns", {"EntityID", "Date", "Hour", "DeviceID"}, { {"Measure1_Per_Hour", each List.Sum([Measure1]), type nullable number}, {"Measure2_Per_Hour", each List.Sum([Measure2]), type nullable number}, {"Measure3_Per_Hour", each List.Sum([Measure3]), type nullable number}, {"Measure4_Per_Hour", each List.Sum([Measure4]), type nullable number} } ) in #"Grouped Rows"
- F003Yum5 months ago
Helper I
Anonymous
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 - Anonymous5 months agoNot applicable
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.