? Pending

User tests: Successful: Unsuccessful:

avatar Hackwar
Hackwar
20 Jun 2018

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.

avatar Hackwar Hackwar - open - 20 Jun 2018
avatar Hackwar Hackwar - change - 20 Jun 2018
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 20 Jun 2018
Category Administration com_finder
avatar csthomas
csthomas - comment - 20 Jun 2018
avatar Hackwar
Hackwar - comment - 21 Jun 2018

Indeed. Even more reason to simplify the code.

avatar Hackwar Hackwar - change - 26 Jun 2018
Labels Added: ?
avatar carlitorweb carlitorweb - test_item - 26 Jun 2018 - Tested successfully
avatar carlitorweb
carlitorweb - comment - 26 Jun 2018

I have tested this item successfully on df11b73


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20816.

avatar wilsonge wilsonge - change - 1 Jul 2018
Status Pending Fixed in Code Base
Closed_Date 0000-00-00 00:00:00 2018-07-01 13:55:23
Closed_By wilsonge
avatar wilsonge wilsonge - close - 1 Jul 2018
avatar wilsonge wilsonge - merge - 1 Jul 2018

Add a Comment

Login with GitHub to post a comment