I agree with you 100%, with the vbulletin fulltext search it just used to crash the server. Re-installed the hack and it works perfectly now :) but I think this only affects the larger forums.

Zachery, you had made a post here: http://www.vbulletin.com/forum/showp...82&postcount=1


... in which you answered the question "How do I turn on Debug Mode". The problem is that you never stated where those code changes had to be made. You never mentioned which file/template you were referring to. :)

We realize that this search is not the answer for larger forums and that is why it is unsupported. We don't want to encourage users to enable this in hopes it will solve all of their problems. It is simply a test to show that we can return the same results that we would return when using our postindex. If you compare the results with fulltext turned on and off, you will see they are very close. You should also compare the search results of any hacks that are perceived to be very fast to this. I'm confident that you will find that those results may very greatly as some things must be sacrificed in order to achieve speed.

This is where I have an ambitious plan to create a dynamic search system that can learn what the bad things to search for are and use less intensive queries to return less than perfect results.

So if I'm on a music forum and searching for The The this would be bad ;)

Hate to be the thread idiot, but for the life of me, I do not see any Section in the vBulletin Options entitled "Version Info and other Untouchables". I downloaded and upgraded to 3.03 this afternoon. Has there been a change in options.php today?

You also need to enable debug mode ;)

I'm sorry to read this now. I know you stated it was unsupported, but I'd rather have had this specific info (not good for larger forums) before activating it and then being forced to disactivate it and resort to Google search, while waiting for further optimizations. Silly me. Not your fault or anything.

What you say is true - precision and accuracy in searching is sacrificed the more you optimize the search by removing relevancy and other things like that.

However, personally, and my forum members would agree, I would rather have a relatively inaccurate search engine and a site that actually remains online and runs fast, than a great search engine, but one which hangs the site and causes apache and mysql to crash. :) A poor search engine is better than no search engine at all. So far, my members haven't noticed anything different - and this is with just serving them 100 results.

The truth is though, is that this is a limitation of MySQL and MyISAM/ InnoDB tables, and not an intrinsic problem with vBulletin, which is greatly optimized as it is. I do appreciate Jelsoft working on releasing a fulltext search early, when they didn't have to. Good job with that.

I am waiting the day I can have fulltext search and row-level locking together - at the moment they are mutually exclusive with MyISAM.

Freddie... is it possible to have some quick fix to speed up the current full text search option? I'm available to test things, as, as of now, I was forced to disable and there's no way I'm gonna reindex everything under the old option (yes, I emptied the search table, call me stupid, I know I am...). 2.5 million posts board, with 250+ users online...

Duh, thanks. I indexed my database, enabled mysql full text, cleared the vB search index, dropped the word table, wrote in the quick hack for more optimized search by user name. All seems to be running smoothly (on a development server). I think resetting the mysql minimum word length from 4 down to at least 3 is going to be pretty standard procedure too.

But I guess the question begs... what's the benefit? I'm reading about some performance issues here on big boards. We have a small board (150K posts). I don't have the luxury of load testing this implementation, so it would be sort of trial by fire to launch it live. Are there any basic comparisons between vB search and mysql full text that I could measure right now? Query response times? Memory useage? Details?

If all of this just serves to reduce the size of the overall database, and eliminate the hassle of maintaining the cumbersome vb search index... and all other things from the user perspective remain equal... then I'm not so sure if it is really necessary at this point for us. Comments?