Are TI Query type views stargates?

[Steve Rowe]

Just picking over items in the cfg file and came across this

AllRuleCalcStargateOptimization
The AllRuleCalcStargateOptimization parameter can improve performance in calculating views that contain only rule-calculated values.
Parameter type: optional, static

Typically, Cognos® TM1® performs calculations for standard consolidations and then calculates values for rule-based consolidations, which may end up overriding values in the standard consolidations. The AllRuleCalcStargateOptimization parameter provides optimization that first checks if every value in the view is rule-calculated and then proceeds as follows:

If every value in the view is rule-calculated, then Cognos TM1 skips the unnecessary calculations for standard consolidations and just performs the rule-calculated consolidations.
If the view contains even a single value which is not rule-calculated, then this optimization parameter will have no effect.
When this parameter is set to True, some additional processing will take place for every view that is requested to first check if the view contains only rule-calculated values. For most views, this additional processing is minimal since the optimization is stopped after the first value in the view is found to be not rule-calculated.

To enable this parameter, set the parameter's value to T in the Cognos TM1 server configuration file, Tm1s.cfg, as follows:

AllRuleCalcStargateOptimization=TThe default setting is disabled (F).

I do a lot of work with rule only TI Query views and am wondering if this will deliver any performance benefits, but are TI Query views stargates under the hood or is it just user views? I assume everything is a stargate under the hood.

Anyone used this cfg in anger and got any benefit?

Cheers,
Steve

[TableManagerOne]

I suspect not, since there is a best practice floating around which recommends "priming the cache" by calling ViewConstruct before running the query. However, it would probably be easy to confirm by enabling the stargate debug logger, which will emit a message on stargate creation. One thing to watch out for though is that with a certain incantation of configuration settings and evaluation conditions, references in the calculation statements may be satisfied by the creation of an "internal stargate" (which would also show up in the log and may be misleading.)

[Duncan P]

My recollection of my only real use of this option was that it performed like a dog, and I suspect that this was because it was checking every cell in the view and not just the fed cells. Please correct me if I'm wrong TableManagerOne.

The key thing that makes this option significant at all is that under normal circumstances even if a view is completely rule calculated (e.g. using DB from another cube) TM1 will create a stargate by adding up all the leaf values that feed into the view. If these leaf values are themselves calculated this can be horrific. However the way round it is not to use this option. It is to make all measures that you will be reading parents. Whether you use individual children or a common child will depend on how the measures are fed. If they are all fed from the same source then you can use a single child, which you can set to

Code: Select all

[] = N:1;

and which you feed from the same source from which you would have fed the original measures.