Wikidata Query Service/Problematic queries

This page lists queries which have some problems running in Blazegraph. Usually that means that we think they should be running fine but for one reason or another they do not. Note that this should not include queries that time out for legitimate reasons - like trying to scan repeatedly through whole database in 30 seconds or missing data triples, etc.

Buggy queries
Queries that do not return correct result, throw unexpected exceptions, etc.

Empty response
This query produces a completely empty response.

Empty response
The following query should give me the events that happened on the same day as today. It works though when I remove the label function & article URL lookup.

({SPARQL|query= SELECT distinct ?article ?event ?date WHERE { ?event wdt:P31/wdt:P279* wd:Q1190554. ?event wdt:P585 ?date. ?event rdfs:label ?eventLabel .   	?article schema:about ?event .    ?article schema:inLanguage "en" .    ?article schema:isPartOf .    SERVICE wikibase:label {       bd:serviceParam wikibase:language "en" .    }     	# events on the same day	#FILTER (datatype(?date) = xsd:dateTime && month(?date) = month(now) && day(?date) = day(now) ) } LIMIT 5

})

This query gives me only a timeout.

Hard queries
These queries time out or take a lot of time despite the fact that they should be simple. Each query should be accompanied with an explanation why we think it is taking more time than it should.

UNION + BIND
The query works fine if BIND statements are eliminated. BINDs should not add to query execution time since they are static data.

Number of items in class (BIND + PATH)
As BIND is a constant here, it should not affect speed, however without bind the query is fast, but with BIND it times out.

Nested subqueries
Internal subquery finishes in 465 ms and by definition returns one result. However, whole query times out even though external query should be a very simple lookup.

Optimizer failures
These queries work well with optimizer disabled but not by default.