| Lucas_Werkmeister_WMDE created this task. Lucas_Werkmeister_WMDE added projects: Wikidata, Wikidata-Query-Service. Herald added a subscriber: Aklapper. Herald added a project: Discovery. |
I was playing around with WDQS’ performance when checking very large subclass hierarchies, for example up to “entity” (Q35120), and discovered this weird difference when you move the class into a VALUES clause.
This query (link) runs very quickly (~250 ms):
SELECT * WHERE {
VALUES ?class { wd:Q35120 0 }
wd:Q3244512 wdt:P31/wdt:P279* ?class.
}This almost identical query (link) times out:
SELECT * WHERE { VALUES ?class { wd:Q35120 } wd:Q3244512 wdt:P31/wdt:P279* ?class. }What’s the difference? In the second query, I removed a 0 from the VALUES clause. The 0 doesn’t contribute to the results, but apparently it makes BlazeGraph choose a faster execution path.
Adding a LIMIT 1, or disabling the optimizer, does not make a difference. Adding a class that does contribute to the results instead of 0 still makes the query run fast. Inlining the VALUES clause to wd:Q3244512 wdt:P31/wdt:P279* wd:Q35120 is just as slow as the version with the single-value VALUES clause.
I’d report this at BlazeGraph’s JIRA myself, but unfortunately I can’t currently sign up there since their CAPTCHA endpoint returns 500 Internal Server Error (“java.io.IOException: No space left on device”).
Cc: Aklapper, Lucas_Werkmeister_WMDE, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
