Egregoros

09:25:50.777 [info] Pruning objects older than 90 days, keeping non public posts, keeping threads intact, pruning orphaned activities

Running the forbidden task ;)
pleroma-pruned-db-winning.png

@phnt let me know how big ur db is after. i ran this on my old pleroma db (after getting the sql query out of the debug logs cuz the mix task kept timing out) and it went from 127gb to 127gb

@pernia @phnt manual activities table pruning has always yielded the most gains for me

@pernia @phnt decayable was about 130 and I knocked it down to 20 between manual removal and pleroma's built in tools

@pwm @phnt damn. what queries did you run manually?

@pernia @pwm

delete from activities where data->>'type' = 'Announce' and split_part(data->>'actor','/',4) = 'relay';

was likely one of them

@phnt @pwm
>salon 78gb
>delete from activities where data->>'type' = 'Announce' and split_part(data->>'actor','/',4) = 'relay';
>DELETE 7018354
>salon 78gb

that did NOTHING. here's the screenshot if u dont believe it. its an old dump.
image.png

@pernia @pwm You have to VACUUM FULL the table to regain disk space you mongoloid.

@phnt @pernia yeah you can check this with pg_relation_size and pg_total_relation_size or whatever they are called. The former is the logical size on disk and the latter is the actual disk use

@phnt @pernia also if postgres says it deleted rows then it deleted rows

@pwm @pernia It is more complicated than that. pg_relation_size is the disk size for one fork of the table (main, init, vsm,...) pg_total_relation_size is all of those together, which is what \l+ in psql uses. To calculate estimated disk size after a delete without VACUUM FULL, you need to get the size of tuples in the table and do the same for indexes.