Last modified: 2013-06-18 14:42:45 UTC
If the parameter $smwgQMaxSize is set to a value of 16 or more, the whole MW-page is not reacting anymore. Best regards, tkrueger73
For infomation: I found that, if a query with $smwgQMaxSize higher than 15 is done, the process "msqld" is staying at 100% cpu load all the time. Checking msqlyd with mtop, I found that for each query I had a threat in an endlessloop for more than one hour. It was impossible to kill this "crashed treads". Only solution was stopping and restarting the mysql server. I have no deep knowledge about SMW and mysql, but maybe my comments are helpfull for somebody with more experience. Best regards, tkrueger73
Please provide further details on the problem. Especially we need an example URL where the problem can be seen, or a detailed description of the environment where the problem occurs (version numbers of all involved software, details about the query and about the contents of the wiki [esp. the data on Special:SemanticStatistics], "format=debug" output of the query). In general, the very purpose of $smwgQMaxSize is to prevent such queries. There will always be a size of query that is not doable for a DBMS any more. Performance can always be improved, but it is not a bug if there exist large and complex queries that are out of scope for your DBMS. Nothing scales indefinitely.
I decrease the importance of this bug since no further details have been provided, and since SMW already includes a number of features that are specifically there to prevent this problem. In general, SMW cannot prevent administrators from explicitly removing the normal restrictions on query complexity (or force them to suitably sharpen these restrictions for very large or busy wikis). I do not know what else SMW could do, since there will always be limits to what is possible with today's DB technology. Changing SMW to always use the most conservative restrictions to prevent hitting these limits (thus taking the control from the administrator, preventing mis-configurations) does not seem to be a good solution. Maybe some documentation could be added to increase awareness, but for this it would be useful to know at least in which environments the problem occurs now.
This bug hasn't seen any update during the last two years and it is unknown if this bug still relates the current SMW 1.8/SQLStore3 therefore it is set to won't fix. Please feel free to reopen this bug again if it applies to SMW 1.8.
Agreed to the WONTFIX. However, it is quite possible that this bug is partly addressed by the recent changes in SQLStore3. At least we have much better and table that should help MySQL to find good query plans in many more cases than before. There will always be practical limits, but I hope we have pushed them a bit.
