We currently lack an efficient index for the "related_account" + "method type" filter combination when fetching transactions. To handle this efficiently, we would need to de-normalize and duplicate the "method type" field in the "runtime_related_transactions" table (and similarly for consensus tables).

This would allow us to create an index that includes both the "related_account" and "method type" fields.

Since this is a very common and useful filtering combination, this de-normalization is justified for this case, but we should aim to limit such changes where possible.