
From our discussion: Phase 1: (We can access these data by API and by direct DB access) Phase 2: Phase 3: Phase 4: Provided dayly statistics calculation for PQ, CQ: We really do not need keep statistics infotags as we have statistics for info and infotag filter, so we can easily get info0tag statistics with simple join. Now statistics process is run by dayly scheduller after aging and materialized values recalculation provided http://localhost:8088/ceqws/jersey/math/aging?type=0^{}  aging Now statistics* table is the only way to test. hmm  what if we import a feed which has activities which are a few month old ? Actually this is what I am doing right know e.g. importing SunSpace ATOM feed for the last few month. Mayb we need a parameter to define the aging start date That should work for activity older then a day. Try http://mb.sunsolutioncenter.de/index.php/activitystream?days=50&pagesize=5000^{} You can change days and pagesize The problem was the first statistics calculation did for previous day only (the following statistics starts from date of last calculated one). I changed behaviour, now the first statistics is calculated for the whole period till previous day. Now the progress of statistics calculation can be observed only in the server.log, the aging?type=2 only starts the process. 
My proposal was keep in cache tables: dayly statistics for last week, weekly per last month, then monthly.
That significantly reduce the amount of stored data.