User tests: Successful: Unsuccessful:
While debugging com_finder, I stumbled upon this "optimisation". As well as the artificial sharding, this might have been true at one point, but this doesn't hold up today. Up till now the code created 2 queries, one to find the exact term and one for the stemmed term. It then did a UNION on the result. According to the comment, this is supposed to be faster than doing a simple OR in the WHERE.
I've tested this and couldn't measure a difference, mainly because my testdata only has 14k rows in that table. Doing an EXPLAIN on the query results in a rather complex explanation for the UNIONed query and one simple row for this new query. This new query is one simple index lookup. I honestly don't believe that the original query is any faster than this one and considering the maintainability and the reduced output in the debug mode, I'm proposing this here.
No way to test this, other than that the search works the same as before.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_finder |
Indeed. Even more reason to simplify the code.
Labels |
Added:
?
|
I have tested this item
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-07-01 13:55:23 |
Closed_By | ⇒ | wilsonge |
Newer databases use index merge optimization:
https://dev.mysql.com/doc/refman/5.5/en/index-merge-optimization.html
https://www.postgresql.org/docs/9.2/static/indexes-bitmap-scans.html
This way you do not see the difference.