Prune old Update activities #683
No reviewers
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#683
Loading…
Reference in a new issue
No description provided.
Delete branch "Oneric/akkoma:db-prune-old-updates"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Plus fixing a typo in the test factory and expanding the
prune_task
test.Followup to IRC question/discussion; as far as I can tell already processed
Update
activities serve no purpose anymore and just bloat the DB (conceptually this holds true for all types of updates and i had closer look at updates of: users, notes and for poll vote updates no activity ever showed up in the DB to begin with for me).The last commit merging the different, simple prunes seems sensible to me, but I admit I didn’t do any actual perf measurements; if you’re unsure about it, feel free to just drop the last commit during merge.
8cc04c9e53
to4fa1183f6a
seems good, I'll try it out locally to make sure nothing explodes soon
@ -31,3 +15,1 @@
from(a in Activity,
where: fragment("?->>'type' = ?", a.data, "Remove") and a.inserted_at < ^before_time
where:
ok the one thing that does mildly concern me here is the size of this query - the reason i split things up before is to make queries as short and self-contained as possible, so reduce the chance of things timing out
for example, on my production database, running a select over these types takes ~16s
whereas just running for one type at a time takes less than a second
probably due to index searching being very easy
I guess the query optimiser isn’t smart enough to also use the context index for sets, oh well
Thanks for testing perf on real world system, i now dropped the last commit (and rebased; no changes to the first two commits necessary)
4fa1183f6a
to1a7839eaf2
nothing exploded, so i think that is a good sign