When storing data in fusion_place that includes multiple items in a single row, such as journal entries, it is common to assign members of the Note Item Dimension to each item. In this case, since each item is individually indexed, the index size increases.

In fusion_place ledgers, the index tends to increase in proportion to the “Number of Records × Number of Physical Dimensions”^[1]. Therefore, when handling a large volume of data, the growth in index size becomes significant. This increase in index size leads to greater memory consumption, which may affect server performance.

To address such situations, applying a Dense Index to the Note Item Dimension makes it possible to reduce both index size and memory consumption.

If a Note Item Dimension is used in the ledger, you can enable “Apply Dense Index to Note Item Dimension” in the Ledger Definition to apply a Dense Index to the Note Item Dimension instead of the conventional bitmap index.

Conventionally, when filtering using a bitmap index, the filtering was performed considering all combinations of members for all physical dimensions, including the Note Item Dimension. By applying a Dense Index, the Note Item Dimension no longer needs to be considered for bitmap index filtering, so the “Number of Member Combinations” in the index is limited to only the physical dimensions excluding the Note Item Dimension. As a result, the load on the filtering process is reduced.

For example, if you have a journal with 10 items, each with a value, the number of indexed records can be reduced to about one-tenth.

Additionally, if you set the scenario’s minimum period unit to “Y,” and use a separate “Journal Period” dimension (instead of the Relative Period Dimension) to represent monthly breakdowns, the memory-saving effect of the Dense Index becomes particularly significant.
For more information on the method and purpose of delegating monthly breakdowns to the “Journal Period” dimension, please refer to Q&A: Slow Display in Browser Towards End of Fiscal Year.