When working on RHQ-1950, and talking with Joseph, it became clear that execution time for our CheckForTimedOutOperationsJob will most likely grow as the the size of the RHQ_OPERATION_HISTORY table grows.  This is because we execute ResourceOperationHistory.QUERY_FIND_ALL_IN_STATUS to find all IN_PROGRESS queries.  The status field is stored as an unindexed, string field.  So, we're looking at a table scan for each execution of the query.

This jop currently executes at 1 minute intervals.  This is down from 10 minutes due to the work in RHQ-1950, but the interval is probably unimportant. What is important is the amount of time the job can run if the op history table grows large.  How large before this may be a problem is not currently known and should be determined as the first step of this Jira.  In that way we can determine whether we need to do some query/db work to resolve this issue.

Putting in index on the current field probably will not solve the problem given it's character nature and low cardinality of values.  An alternative suggested by Joe would be to change the field to a numeric, with enum values corresponding to the progressive states of an op. E.g.  (inprocess, cancelled, completed, failed).  Giving this field an ordered index could give us the ability to do range scans efficiently.

I suggest we at least understand the perf of the current query in the 1.2 timeframe so as to know whether a change is required in the short term.