https://bugzilla.wikimedia.org/show_bug.cgi?id=21868
Markus Krötzsch <mar...@semantic-mediawiki.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Markus Krötzsch <mar...@semantic-mediawiki.org> 2009-12-23
17:31:43 UTC ---
The query parser is pretty much ad hoc, but it works as expected in the cases
you mention. The parser generally tries to ignore errors and interpret whatever
remains of the query. In your case, there are no valid conditions in the
malformed query, so that the query ends up selecting all pages. The same
happens for the empty query. Note that you can use "format=debug" if you want
to have more information about how the query was understood without actually
executing it.
One could (and probably should) disallow queries for *all* pages, but the main
issue here is that such a simple query actually freezes your database.
Normally, the query without conditions should be easiest to answer (given that
it imposes a small limit as in your case). I think the problem here is that the
SQL generation adds another instance of the smw_id table (SMW's "page table")
to the query, thus enforcing a redundant inner join of potentially large
tables. I have now improved the query generation process to avoid this, so the
performance of the empty query should be much improved.
I have also added a new parameter "$smwgIgnoreQueryErrors" that can be used to
specify if queries should be executed at all if errors occured during parsing
or preprocessing. The default for this setting is "true." Together with the
above, this should fix this specific bug.
There is still much room for optimising the SQL query generation. Ultimately,
it might be worth to investigate the use of more specialised storage backends
than MySQL (relational DBs are not particularly great for SMW's data model), or
to adopt a more sophisticated table layout in SQL (especially large inner joins
are an issue with the "single table" approach of SMW). I am also somewhat
disappointed about the bad performance that you indicate, given that the inner
join is done over the primary key of the tables: retrieving these 21 results
should really be no problem in spite of the large table as such!
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
