The limitation appears to be coming from RHQ_NUMBERS table, which only has 60 values...
The query goes like:
SELECT timestamp, max(av), max(peak), max(low) FROM (
(SELECT timestamp, avg(value) as av, max(value) as peak, min(value) as low FROM (
(SELECT beginTS as timestamp, value
FROM (select 1340075965000 + (5040000 * i) as beginTS, i from RHQ_numbers where i < 120) n,
I noticed RHQ_numbers only has 60 values. So I ran the following SQL:
insert into RHQ_NUMBERS values(60);
insert into RHQ_NUMBERS values(119);
and I could now get back 120 datapoints. Which is good. I don't suppose this is the recommended approach to fixing this? Yet, it seems to work fine. (Why is RHQ_numbers needed at all? I suppose it is a SQL thing.)
RHQ_NUMBERS is referred to as a numbers table (see http://sqlblog.com/blogs/adam_machanic/archive/2006/07/12/you-require-a-numbers-table.aspx ). I don't see how it would hurt for us to add more numbers to the table - create a BZ for it.
We need to be careful here, because the number in the RHQ_numbers may need to correspond to the number that is input into the SLSB methods.
The current UI graphs require the 60 data points. This may break if we just change it to 120.
Also returning 120 data points will not give you a larger time frame per se, but a finer resolution for the timeframe selected.
It would be good if the number of points would be something that could be injected into the SQL query.
Wrt the raw data export - data > 7 days old is aggregated, which means that there is avg/min/max - what would you expect to see for the old data, given that the /raw url will only return one metric (the raw one for the last 7 days)?
Thanks for opening BZ