Prune old Update activities #683

Merged
floatingghost merged 2 commits from Oneric/akkoma:db-prune-old-updates into develop 2024-02-19 13:59:34 +00:00
Member

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.

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.
Oneric force-pushed db-prune-old-updates from 8cc04c9e53 to 4fa1183f6a 2024-02-10 01:14:19 +00:00 Compare

seems good, I'll try it out locally to make sure nothing explodes soon

seems good, I'll try it out locally to make sure nothing explodes soon
floatingghost reviewed 2024-02-17 12:03:51 +00:00
@ -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

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
Author
Member

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)

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)*
Oneric marked this conversation as resolved
Oneric force-pushed db-prune-old-updates from 4fa1183f6a to 1a7839eaf2 2024-02-17 16:06:20 +00:00 Compare

nothing exploded, so i think that is a good sign

nothing exploded, so i think that is a good sign
floatingghost merged commit 3e24210e9f into develop 2024-02-19 13:59:34 +00:00
floatingghost deleted branch db-prune-old-updates 2024-02-19 13:59:34 +00:00
Sign in to join this conversation.
No description provided.