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
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.

This query gives me only a timeout.
 * The problem is probably because the  results in about 2.000.000 events
 * The following query without the Label service barely manages this in 37 seconds. Adding the SERVICE resulted in 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.

Cities in Saxony
workaround as of 2016-12-17, based on a solution for a related problem:

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.

Number of statements in the database by summing each wikibase:statements
It was possible to get the result of this query a month ago

Now we reach timeout. Workaround is to use precalculated count of triples which have rank:

Timeout statement is reached
So I am trying this semi-simple query and getting timeout. Any ideas what to do (other than limiting the query size)?

Solution: actually, if you look carefully, the first triple is, which tries to select all people and bind occupation to variable Q11063. To select people with occupation=astronomy change the first line to

Server error: Unexpected end of JSON input
A variation of the previous query, returns "Server error: Unexpected end of JSON input".

Solution: same as above. This query tries to select all people with any occupation. To select people with occupation=philosopher, replace first triple with.

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

Deprecated statements
u