Is there a data expiration strategy for runs_logs? https://bugzilla.mozilla.org/show_bug.cgi?id=703967 refers to the builders table, but on production, the runs_logs table is 100G right now.

Bug 703967 is about both the runs table and the builders table. runs_logs uses |REFERENCES runs(buildbot_id) ON DELETE CASCADE| so should be resolved by that I presume? (http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/tip/schema.sql)

Hrm, the problem is that DROP PARTITION isn't a delete, so there would be orphaned rows. It probably makes more sense to not bother with partitioning on the runs table....but to put an index on (endtime) and then the delete won't be so slow. We will need to defragment the tables to reclaim space.

Can we do this soon, please? the runs_logs table is 102G. Is this something we can do - put the index on, so the delete isn't so slow? and can we schedule a time when we can defragment the table, to free up space? Maybe July 4?

(In reply to Sheeri Cabral [:sheeri] from comment #3) > Can we do this soon, please? We're happy for this to happen as soon as possible, however it's not anything we can do ourselves - we were waiting on bug 703967.

moving to that bug.

Fixed by bug 703967