Notices by Yukkuri (iamtakingiteasy@eientei.org), page 7

Increasing postgres statistic level turned out to be way more useful than anticipated; in case of a new user, with page size exceeding number of activities matching user timeline, planner was estimating over 200-300k rows and had to do filtering on id desc nulls last index instead of using bitmap scan on recipients gin index when filtering for recipients intersection, causing query to stall for several minutes.

(a 10 times increase from base 100)

reduced estimates to ~1-3k rows and query time to 20-50ms with just bitmap scans of respective indices.

Another option might've been to force planner to scan ordering index after applying bitmap scan with putting everything but order/limit into subquery, but for it to work, subquery must include all Ecto preloads, which isn't something Ecto currently supports.

ORMs are a lie, as usual.

@verita84_uwu @mint Looking at their repo, at least migration-wise it should still be possible to detransition. Most migrations are not destructive, some even providing the down/rollback option. You could start with mix ecto.rollback --to 20220108213213 (last upstream migration). Some migrations do not define down option, but those are just adding tables/columns, you would be able to drop them manually, just go through files between

https://akkoma.dev/AkkomaGang/akkoma/src/commit/6a19fbac2f0d9c05bc25159d6dc19b89d19f2241/priv/repo/migrations

and

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/priv/repo/migrations (or corresponding to the akkoma version that is installed)

Note that you do need to drop at least announcements table, as pleroma migrations would try to add it themselves, it would be safer to revert every change.

And then migrate everything up from upstream, it may even work.

Testing afterwards if everything works would be tedious, but doable. No need to take cosplay to 51% extreme just yet.