leercontainer-bugzilla wrote:

See also:
http://meta.wikimedia.org/wiki/Stop_word_list
http://en.wikipedia.org/wiki/Wikipedia:Common_words%2C_searching_for_which_is_not_possible

we dropped mysql 3.x support with MediaWiki 1.6.

MySQL 4 and later still have a stopword list, though they aren't as unpleasant as the behavior in previous versions.

It would be nice if we could reliably disable it per table or something...

Yes, please override it with an own customizable list for users without lucene search.

Created attachment 7143
MaxSem's slow patch

Best I could come up with - but still pretty slow, maintenance/rebuildtextindex.php runs 30% slower with it. Tested several solutions (oneo of them could be seen in the patch, commented out), but none of them had satisfiable performance. I therefore don't dare to commit it into the trunk. Leaving the patch here so that other folks could take a look at my approach.

Attached:

• Bug 25446 has been marked as a duplicate of this bug. ***

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

See http://dev.mysql.com/doc/refman/5.1/en/fulltext-fine-tuning.html which says "To override the default stopword list, set the ft_stopword_file system variable. ... if you change the stopword file itself, you must rebuild your FULLTEXT indexes after making the changes and restarting the server. To rebuild the indexes in this case, it is sufficient to do a QUICK repair operation: REPAIR TABLE tbl_name QUICK;"

So, while you can't "reliably disable it per table", you *can* disable it without compiling by setting ft_stopword_file to "", restarting, and then rebuilding the table.

(In reply to comment #8)

So, while you can't "reliably disable it per table", you *can* disable it
without compiling by setting ft_stopword_file to "", restarting, and then
rebuilding the table.

A task for installer?

Just checking: in the times of Cirrus Search, are MySQL's stopwords in English causing any trouble to searches in non-English wikis?

No, nothing like this from the SQL search implementation affects Cirrus' implementation.

Given this is not affecting Wikimedia sites (as the original report seemed to care about) and that non-Wikimedia sites using MySQL as a search engine can use T2352#29893 as probably the cleanest way to achieve this, I would decline this, unless someone is very, very insterested or wants to volunteer for an installer patch (which may not work properly anyway, as it needs database server access, which not all installations might have). Maybe it could be considered for a container-based distribution, only?

MediaWiki is still a product for third parties, so this is a valid bug, even if no WMF engineer is going to work on this.

@MaxSem My comment is not "based on WMF needs". As a MySQL-guy, I think it is almost impossible to fulfill (I do not think the installer can do that reliably), and that the right way to fix this is to document the workaround as the right way to do it. If it was on mediawiki, I would expect it to work on all cases where the requirements are right, and the only way to do it is more of an infrastructure/deployment fix (unless mediawiki starts to start and stop the database by itself).

Discovery-ARCHIVED only maintains CirrusSearch (i.e. Elasticsearch) backed search, so this is out of scope for us; removing the Discovery-Search tag.