Hi Igal, All suggestions are welcome :) Supporting this feature shouldn't be too difficult in theory because it is already working with this kind of aggregation (month are built from days, years from months...). The main problem is scalability for stats which require uniqueness like number of users or number of edits *per page*. That's why yearly stats can actually be disabled on some big wikis. So it would be feasible but with edits limitations for the range (like 3-5 millions) and it would be very slow to load with lots of edits. Akeron 2017-07-31 14:29 GMT+02:00 יגאל חיטרון <khitron(a)gmail.com>om>: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Thank you. I will not say that I understood your explanation, but I'll try: If you have number of viewers of some page for every year, can't you get the sum of them and compare with another page to sort them? And the same for the number of some user's edits? Igal On Jul 31, 2017 17:19, "Akeron" <akeron.wp(a)gmail.com> wrote: is statistics Jan this briefly then _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, Jul 31, 2017 at 7:18 AM, Akeron <akeron.wp(a)gmail.com> wrote: One way to handle the scalability problem is to use HyperLogLog counters. These are an approximate algorithm for which you can store daily counters, and then merge the counters to get weekly/monthly/etc, avoiding the cost of doing the calculation over something like an entire year just for the one stat. Of course because these are approximate they may not be exactly what you are looking for, just an idea. _______________________________________________ Analytics mailing list Analytics(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics