This article is part of a series on Polaris best practices. Click here for more Community content or visit Anapedia for detailed technical guidance.
Polaris keeps track of intersections in a model using a dimension index which allows efficient retrieval of cell data even in an extremely sparse model. This index has a limit which can be calculated using the information in Anapedia, which is evaluated per line item, not at the model level. This article explains what the dimension index total (DIT) measures, how the 64-point limit works, and why staying under that limit is a starting point for a well-built model rather than a finish line.
What the DIT is
The DIT is a structural measure. It's the sum of the index scores for every dimension applied to a line item, where the score for each dimension is derived from the total number of members in its underlying list, including parent levels and any top-level item. Time and Versions count as normal dimensions and contribute to the total the same way any other list does.
Every line item in a Polaris model carries a DIT, and that total must not exceed 64. If adding a dimension or importing new list members would push a line item over 64, Anaplan blocks the change and returns the error citing the affected line item and instructions to “Reduce the number of list items or use fewer dimensions”.
Within that limit, a line item can still support very high dimensionality. A line item touching 2,000 products, 200 cost centers, 5 currencies, and 4 scenarios over time can remain under 64. So can a line item spanning 15,000 components across a 15-level bill of materials and 10 plants. The index and its limit is a structural measure Polaris creates to determine where data sits.
What the DIT isn't
It's easy to read the 64-point dimensional limit as the only architectural consideration for a Polaris model, but it isn't. The DIT is a hard structural limit, not a performance indicator: a line item can sit comfortably under 64 and still be slow, use a huge amount of memory, or be otherwise poorly optimized.
Using the example from Anapedia, a line item spanning 2,000 products, 15,000 components, a 15-level bill of materials, and 10 plants over a 2-year monthly calendar with quarter totals (35 time periods) has a DIT of 39, comfortably under the limit of 64. But that same line item has 157,500,000,000 (that’s 157.5 billion!) addressable cells. Populating or calculating a meaningful share of a line item at that scale could be extremely expensive to run, regardless of how comfortably its DIT sits under 64.
Three distinctions are worth calling out explicitly:
- DIT is not memory usage. The dimension index represents every addressable cell, populated or not. Memory consumption is driven mainly by populated cells. A line item can have a low DIT and still consume significant memory if its populated cell count is high, and conversely a high-DIT line item that is very sparse may use little memory at all.
- DIT is not affected by Summary Method. Setting Summary Method to None reduces calculations performed and populated cell count, but it doesn't reduce the DIT. The dimension index total is calculated from the underlying list structure regardless of whether summary methods are used.
- DIT has no effect on calculation optimization. Two line items with the same DIT can perform very differently depending on formula design. A line item under the DIT limit that holds dense data, has high calculation complexity, uses unguarded formulas, or that splits sparse logic into separate line items unnecessarily, can still be slow performing. Staying under 64 says nothing about whether the formulas driving that line item are efficient.
In short: the DIT limit tells you whether Polaris can create the index needed for the sparse engine to assess the line item. Remaining within this structural limit does not guarantee a performant model.
Calculating and managing DIT
Working out a dimension's index score and applying the key tactics for staying under the limit are documented step by step on Anapedia. This work should happen early, during the architecture phase. If you're following the recommended Iterative Development in Polaris, DIT errors won't surface until step 2, when you build out the TEST environment, so waiting to check DIT until then risks discovering a structural problem well after early design decisions are locked in.
See guidance in Anapedia for key tactics to stay under the DIT limit.
Summary
- The DIT is a structural measure of the total addressable cells in a line item, calculated from dimension member counts, and capped at 64.
- It isn't a measure of memory usage, and it isn't reduced by Summary Method settings.
- Staying under the DIT limit doesn't mean a line item, or the model it is within, is performant. Formula design, populated cell count, and workspace-level size constraints are separate considerations that require their own attention.
……………..
Author: Anaplan’s Theresa Reid (@TheresaR) Architecture and Performance Director. Special thanks to Rob Marshall (@rob_marshall) and Dave Smith (@davesmith) for their contributions.
