SELECT MAX(time_stamp) FROM RHQ_MEASUREMENT_DATA_NUM_1D is very expensive with a huge number of data -- basically Oracle does a full index scan as the existing index is (schedule_id, time_stamp). Putting an index on time_stamp only would remove the FIS burden and speed up this operation. This also follows the similar index on the 1h and 6h tables.
Note, this can only be a shot term solution. For a real fix, we need to "precompute" the data and store them in some separate table row. See https://bugzilla.redhat.com/show_bug.cgi?id=621597
commit 2ba9e1c4cfcb7046bfce34996d4955b0091c08a6 Author: Lukas Krejci <lkrejci> Date: Thu Dec 16 12:23:48 2010 +0100 BZ 656469 - adding a temporary performance measure on the RHQ_MEASUREMENT_DATA_NUM_1D. Having an index on TIME_STAMP column helps the performance of the hourly jobs but a more involv This fix is part of RHQ 3.0.1 as well and therefore was added as schema spec 2.92.4 even though master is currently on schema spec 2.101. This is to support seamless upgrade of the releases, but of course intermittently this is schema spec is not going to get applied until a full dbsetup is executed.
commit 4f29065c937833a03f96d5d09f2f36d9fd5781f9 Author: Lukas Krejci <lkrejci> Date: Mon Dec 20 10:58:40 2010 +0100 BZ 656471 - adding missing index definition in db setup.
The previous commit hash is incorrect. The correct one is: 6d4c02a946fe0117ba033b385a747b0a9d1e133b
QA closing - dev task, not much to readily QE here.
Bookkeeping - closing bug - fixed in recent release.