The “Top Trending Topics” feature in Discourse does not honor date picker/ranges, unlike the “Community health” reports. Mark_Walkom pointed out this disconnect and suggested making the trending topics adjustable by date range, which would be useful for highlighting popular topics and providing feedback.
sam explained that the date range currently only applies to the charts and that adding an adjustable date range for trending topics would be expensive. However, an extra link to explore the data in different time ranges could be added.
A proposal for this feature was shared by joffreyjaffeux, which includes a dropdown menu to select a date range. However, there are concerns about data overload and query performance, with sam suggesting that a timeout should be implemented to prevent slow queries.
Mittineague pointed out that using LIMIT may not be enough to prevent slow queries, as it can still be expensive even with a low limit. joffreyjaffeux agreed and mentioned that a single record can take a long time to process on a large database.
The feature has since been released and is available at the URL /admin/reports/top_traffic_sources in the latest update, as announced by joffreyjaffeux.
You can change the time range for " Community health" reports on the admin page which then updates all the graphs. However this doesn’t apply for the “Top Trending Topics”, which is a bit of disconnect. I did try a few API calls on the report, passing in date ranges, but these also didn’t seem to have an impact either.
I’m not sure how this is calculated, is it as an all time thing, or can we bucket it up into an adjustable range?
The reason is it’d be super cool to highlight trending topics, or to use them to provide feedback to others, eg “hey this is spiking, do we need to do X or Y to reduce the friction?” or “this topic is super active, let’s do a deep dive blog post”.
Oh, the date there only refers to the charts, not to anything else on the page.
Doing top referred over a year would be pretty expensive to say the least. I am open though to adding an extra link there to explore this data in different time ranges.
The first step would be fixing this (which is linked from: admin/reports)
Yeah that does nothing really, if we tell it to run an aggregate on 20 million rows … this can get too expensive fast. We need this thing to time out after 20 seconds and tip the user that … sorry we just can’t run that query for you.
I don’t know what the query looks like, but a typical problem with LIMIT is that it happens after the cost has happened. That is, it’s often more like a “post” filter than a “pre” filter.
