Recent Topics

1 Aug 20, 2010 18:17    

I noticed that the search function is not working as it should. If you look for tile (a manufactured piece of hard-wearing material such as ceramic, stone, metal, or even glass) you get Textile, versatile, etc., which is not what you were looking for. I guess that there many other examples, and I tried the same search in google, which gives the correct result (only tile/s). I think this is a problem in most versions of b2evo, at least it is in 2.4.7 and in the one used in

2 Aug 25, 2010 18:46

Well, after some investigation, I think that (some of) the possible options to get a google-style search function are:

- using RLIKE, which is very much slower than using LIKE, about 20 times in our tests (our database: 50 000 records in items__item, the table weights 300Mb).

- You can still use a combination of LIKE and RLIKE (see in the comment posted by Dave M on September 12 2004 3:44pm) which is much faster, but still slower than LIKE alone (from about 4.5 seconds to 3 seconds in our tests, using 3 words with AND in the standard search function)

- the best one: using FULLTEXT INDEX in post_title and post_content (wikipedia uses it). In our tests, searching for one word in phpmyadmin, using the standard b2evo where_keywords() query applied just to post_title, took 2.9006 sec without FULLTEXT, and 0.0879 sec whith the new index. The difference is huge, but there are some problems: FULLTEXT INDEX with standard minimum word length = 4 takes a lot of disk space. We tried first indexing just post_title, which is of course much smaller than post_content, and the total index space usage doubled inmediatly, so we didn't even tried with post_content. Second, if the table is already loaded with posts, it takes a lot of time to build the index/es.

So we left the search function as it is. But in the investigation found that using SQL_CALC_FOUND_ROWS the search function works faster. As Daniel Hahler says: "We might just use "SELECT SQL_CALC_FOUND_ROWS ..." and "FOUND_ROWS()"..! - available since MySQL 4 - would save one query just for counting!". Very much true, avoiding the most resource consuming query makes the system feel very well. We did it and the search times went down about 30/50%, from 3 sec to 1.5/2 sec (if the server works as it should, wich rarely happens...).

Form is loading...