From Jesse via Slack:

Currently when hermes launches, it tries to find all packets that aren't cleared yet. For doing this it does roughly the following, using tx_search:

pub fn packet_query(request: &QueryPacketEventDataRequest, seq: Sequence) -> Query {
    Query::eq(
        format!("{}.packet_src_channel", request.event_id.as_str()),
        request.source_channel_id.to_string(),
    )
    .and_eq(
        format!("{}.packet_src_port", request.event_id.as_str()),
        request.source_port_id.to_string(),
    )
    .and_eq(
        format!("{}.packet_dst_channel", request.event_id.as_str()),
        request.destination_channel_id.to_string(),
    )
    .and_eq(
        format!("{}.packet_dst_port", request.event_id.as_str()),
        request.destination_port_id.to_string(),
    )
    .and_eq(
        format!("{}.packet_sequence", request.event_id.as_str()),
        seq.to_string(),
    )
}

What we found is that

• it's actually much faster to query by packet_sequence only, then filter by channel/ports in the hermes side
• this is due to tx_search not really having cardinality on each index filter (for this TxSearch subroutine would never be able to optimize which filters to scan through first in effort to minimize search space); with the current TxSearch logic TxSearch might attempt to scan through all indexes that matches source_channel/port + dst_channel/port, which there might be millions.
• Whereas sequence tends to be more unique across channels; it'll only give you N sequences where N is the number of open combination of src/dst