Skip to content

Fix query performance regression in old message detachment

The join used to determine how many messages should be left in the folder was inefficient.

From my (fairly crude) testing it seems like switching to a subquery, as I've done in the patch, uses less than 4% of the time in small data sets, scaling to I believe less than 1% on larger sets. Perhaps the original query somehow wasn't hitting the index? I'm not able able to go deep this morning to fully explore the cause, but before this update I could also reproduce a locked database problem which on the next run didn't occur, with the change in place.

The second query has also been performance tested and found to be more efficient left as a join (instead of a subquery).

A good reminder to more thoroughly performance test all query changes!

Hopefully addresses #921 (closed), fixing an issue brought in with !556 (merged).

Merge request reports