>Firstly, it should be approximately equivalent to prune immediately after submission, but safer: no chance of an OOM during deletion, etc.

My intent with placing it before was for performance but I realized there is an index on the date field for the event tables, which should make the events query (>= date) quick not matter where the pruning took place. Would you agree (my SQL skills are a bit rusty)?

However, I'm not sure I understand the OOM case - we still need to maintain the same references when we delete before as with after (namely a `HealthReportDatabaseStorage`instance and a `ContentProviderClient` instance to get the storage). Can you explain why this could OOM? Is it because an OOM exception would likely be thrown on the document generation query if it was first?

Otherwise, I agree the placement should not matter.

> Secondly, do we want to bomb out if this deletion fails for some reason, or should this be wrapped in a try block?

I've discovered that since we run in the same process as Fennec, if we bomb out, we'll kill Fennec too ([reference](https://bugzilla.mozilla.org/show_bug.cgi?id=740731#c13)).

Thus, we should try/catch in any case, but it's probably good to log this error in some way because (and correct me if I'm wrong) a delete failing is probably either database corruption or programmer error, the latter which we can fix.