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 188.8.131.52 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.