I guess my distaste for overcooked pasta is what keeps me together against the forgetfulness.

I use the timer in the clock app on the phone. But also, I have a dozen preprogrammed timers that I can start from a shortcut on the home screen, and two timers in the swipe-down menu that are accessible even with the phone being locked. These are all implemented with the Automate app (for Android) — which, for better or worse, requires a bit of programming chops, even though the ‘coding’ is visual instead of textual.

It’s likely much faster to fetch the common feed from the database cache or prepared cache like Redis, and apply all this additional data in the app, than do uncached joins. So I’d hope that the apps do this. Especially since you say they use Redis, which of course doesn’t do joins and such, unless something changed in the past years.

To add to other answers, the result for the ‘all’ feed is likely to be cached, either explicitly by the server app or implicitly by the database. Personal feeds are less likely to be cached, since they’re only used by individual users.

Strictly speaking, the db might be looking in an index to choose rows by the communities — but using such a condition is pretty much guaranteed to be slower than not using it, anyway.

The actual answer depends on the actual database organization, of course. Ideally the whole database should be organized around frequent queries.