How ASo Works and how to Design for Performance - Developing Essbase Applications - page 256

Figure 7.10 ASOsamp Design Aggregation using dataload.txt and all recommended views. (From Oracle Essbase
Administration Services. With permission.)
Simple math tells us that these two views are 95.78% and 96.95% of the level-0 view.
now, remember what rule r3 told us:
r3: All queries against the same aggregation level take the same time.
Just as the sorting-needle had to pass through all of the cards in the box, ASo must
compare the bitmap mask (whatever it may be) to all rows of the view. Does it really
serve much purpose to have as Aggregated view(s) a set of rows almost as large as the
original level-0 view? The percentage saving by using either view 15 or 25 will be small
(the size of the card deck to be queried is almost as large as the original). So, in my opin-
ion, no. remember that to process these two views they have to be in memory, and that
is a relatively large percentage of incremental memory for a very small percentage gain.
The situation is even worse if you are memory-constrained and have to compromise
regarding rule r1:
r1: The Input-level and Aggregation-data for all loaded ASo cubes should fit into
memory (or it ain't really ASo).
If these two views are not in memory now, think of all that I/o (input/output)
just to get a view that is only a few percentage points faster. Actually having those
views in a severely limited memory situation will result in worse performance than
if they had never been created. (The exact amount of degradation would depend on
the relative speed of your disk to memory transfers and the exact query distribution
over time).