You can use the Type of SP Grouping for Delta Caching setting to optimize the behaviour of the delta cache.
If a query is based on a CompositeProvider or MultiProvider, you can specify that the data that each of the InfoProviders for the CompositeProvider or MultiProvider supplies is to be treated separately and stored separately in the cache.
The advantage of this grouping is that you do not have to read all data for all InfoProviders again when data for just one sub-InfoProvider changes.
The disadvantage of this grouping however is that it requires more memory space because the data cannot be aggregated using the various InfoProviders. The data is not aggregated until the query is run.
The grouping is only taken into account if the delta cache process is activated for the query.
The following modes are supported:
There is no partitioning. All results for the InfoProvider are merged into one result and cached. If the data for an InfoProvider changes, the cache has to be rebuilt. This is the default setting.
With grouping based on the InfoProvider types, all InfoCubes are saved in a group. The remaining InfoProviders are either stored in one group or stored in multiple groups according to their properties. DataStore objects or InfoProviders that can supply hierarchy nodes are grouped for example.
Open requests for a real-time InfoCube are also stored separately from standard InfoCubes.
Unlike with grouping dependent on InfoProvider types, the individual DataStore objects (advanced) with the modeling property All Characteristics are Key, Reporting on Union of Inbound and Active Table and InfoCubes are also stored separately.
Unlike with grouping dependent on InfoProvider types, the individual DataStore objects (advanced) with the modeling property All Characteristics are Key, Reporting on Union of Inbound and Active Table are also stored separately.
With this setting, all InfoProviders are stored separately.