Forum Discussion

powerbiexpert22's avatar
powerbiexpert22
Icon for Impactful Individual rankImpactful Individual
15 hours ago

Partitions Name - Incremental Refresh

I am using below incremental refresh setting with data archival of last 2 years and incremental period for last 6 months, i am trying to understand based on what strategy Power BI name partitions however i am unable to understand why Power BI created an additional partition for April month as shown below , it should be 6 partitions from May to October 2026 since i mentioned 6 months period. which strategy Power BI use when it comes to naming the partitions

 

 

 

 

Need Help
power bi

2 Replies

  • maruthisp's avatar
    maruthisp
    Icon for Super User rankSuper User
    8 hours ago

    Hipowerbiexpert22​,

    This is normal behaviour with Incremental Refresh.

    The 6 months setting defines the rolling refresh window, but it does not always mean Power BI will create exactly 6 physical partitions.

    If the refresh window starts part-way through a month, Power BI may keep an extra monthly partition to cover that partial period.

    So seeing 7 partitions for a 6-month refresh policy can be expected. Power BI manages those partitions automatically, so normally no change is required.

    Best Regards,

    Maruthi

  • jubinsoni's avatar
    jubinsoni
    Icon for Solution Sage rankSolution Sage
    14 hours ago

    Hi powerbiexpert22​,

    This is expected behavior, and the extra partition is a side effect of how the refresh window is anchored. I am describing it from the documented design rather than from your model, so please verify with the check below.

    What is happening. With month granularity, each partition covers one calendar month, but the incremental window is a rolling range counted back from the refresh date, not from the first day of the month. A 6-month window that starts a bit into April still has to touch the April partition, so you can see seven month partitions (April to October) even though the policy says 6 months.

    To see exactly what the service created, connect to the XMLA endpoint (SSMS or Tabular Editor) and list the table partitions. Partition names follow the period they cover, and RefreshedTime shows which ones were refreshed last:

    -- DAX Studio / SSMS (XMLA connection to the semantic model)
SELECT [TableID], [Name], [RefreshedTime]
FROM $SYSTEM.TMSCHEMA_PARTITIONS

    A few practical points:

    Partition names  -> generated by the service from the period (e.g. a 2026-04 style key); not user-defined
Partition count   -> archive periods + refresh periods + the partial boundary period
Boundary month    -> partially covered, so it is part of the refresh set
Historical months -> only refreshed if they fall inside the refresh window

    If the extra month matters for refresh time, shorten the refresh period by one unit or switch to a daily granularity for the refresh part so the boundary partition is smaller.

    So my overall approach would be:

    Confirm -> list partitions over XMLA, check refresh timestamps
Decide  -> accept the boundary partition, or tune granularity/refresh period
Monitor -> watch refresh duration after the change

    AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.