jonbartels
commented
1 year ago What database engine are you using?
When the text search runs, does your database show a slow query in its slow query logs?
Mirth Connect is probably not applying any precedence to the query operations, it is using a MyBatis mapping to generate SQL then deferring the planning and execution of that SQL to the database. The database is then generating a less efficient query plan.
ANY text search operation in Mirth is likely to be slow because of how text search works. That text search would look at all message content. Message content includes, but is not limited to:
- raw message
- transformed message
- encoded message
- sent message
- response message
- all maps
And that content is PER CONNECTOR. So a text search has to examine SIX different message content types PER connnector AND do a free text search. It won't be efficient.
The usual trick to add indexes could help but efficient free text search indexes are specific to each database vendor. Mirth is also INSERT and UPDATE intensive so adding indexes to improve SELECT could harm write performance.
Your issue is valid. There are strategies to get better free text search results but I think it is important to know the scope of what free text searches in Mirth actually have to do.
Describe the bug If you use one of the "indexed" search options in the MC Administrator (e.g., selecting the FILTERED checkbox), the search is performed quickly. If you add a text search, however, the search takes much longer. It appears that the text search is being performed first, with the results then filtered based on the checkbox (or other filters).
To Reproduce Setup steps: Use a channel with a large number of messages, a few of which have some distinguishing characteristic. This might be the status or a metadata value.
Steps to reproduce the behavior:
Expected behavior The combined search takes about the same time as searching only by the indexed option.
Actual behavior The combined search takes a lot longer.
Environment: