@star@awoo the resulting query plan is also great :D
Index Only Scan using statuses_home_timeline_idx on public.statuses status (cost=0.56..938.74 rows=236 width=54) (actual time=0.122..865491.931 rows=9430338 loops=1)
@kim@wyldtom@awoo Maybe the index isn't the problem; maybe the planner is severely mis-estimating the plan, and therefore building a terrible plan? I heard that that is a thing that happens, when the analyze daemon/vacuum job hasn't been run on a table for a while for some reason
If you are really keen to find out, I'd suggest throwing the query into a very verbose explain analyze, then using a query plan visualizer to get a good overview of what the database is doing, where it is going wrong, and where most of the time in the query is spent. I actually held a workshop about this very recently :3
@awoo@star@wyldtom could you post in the codeberg thread maybe some explain log dumps of the faster user's home timeline queries on your instance? it could be a compounding problem, i.e. shows up as a bit of extra slowness in small queries but gets worse at a much higher rate than linearly. that might indicate poorer than expected postgres performance in general