For this particular experiment, there was a statistically significant 21% CPU time reduction when using IMU. However, there was a statistically insignificant 6.5% wall clock time reduction when using IMU. This means, for this particular experiment, there is not quite enough wall clock time difference to indicate using IMU made an improvement.

Unfortunately, based on this experiment, the significant IMU CPU savings was offset by an insignificant average wall clock time reduction. The experiment was not designed to detect why the wall clock time was not significantly better when using IMU. But I'll speculate: There was a raging DML and physical read-induced IO bottleneck with plenty of excess CPU capacity. So while IMU reduced the CPU consumption, the wall clock time was primarily based on IO. In other words, I reduced Oracle's CPU consumption when where was plenty of available CPU-the classic performance blunder of tuning the wrong thing! However, if the bottleneck were CPU, I should have seen a very significant reduction in both CPU and wall clock time.

It is interesting to note the IMU results varied less compared with the non-IMU results; in other words, when using IMU, query times were more consistent. I suspect it was because there was less segment management, which sometimes requires IO, and IO times can vary widely. Consistent response time is something users enjoy. If you want to irritate a user, give them really fast response times combined with really slow response times.