Over the years, we included almost all possible default group by criterions for getMovementHistoryList, so that in essence, we do not group ... for example, we did 7814c521 . It would be better for performance and more logical to just not group by at all, getMovementHistoryList should just return the list of movements.
This is still possible to use explicit group by parameters in getMovementHistoryList, for example grouping by explanation_uid like we can do in some accounting reports.
I don't have a proper benchmark, but on the instance where we discover the issue, a simple getMovementHistoryList yieliding 112301 results went from several minutes spent in state Removing duplicates (I killed the query after some time) to about 3 seconds.