The only problem with that theory is that you could give Essbase all the ram in the world and it won't necessarily help performance. I've done the testing with caches and you reach a point with very low caches where you don't get any better performance by adding more. Hopefully 184.108.40.206 will help, but the jury's still out... Essbase is almost always CPU bound and not I/O bound -- it's been like that as far back as I can remember. That's why partitioning is such a valuable tool -- you can use more CPU for a retrieval. I'd love it if they'd introduce virtual partitioning.
Scoring disabled. You must be logged in to score posts.