The "SPARQL is slow" question came up in two contexts - Orri, you've answered the "compared to SQL" strand nicely, where the generality of the data model (RDF, application and usage neutral) impacts it.



The other strand in the workshop was that web access demands fast response. It's an discussion of the same shape as the "NoSQL vs SQL" debate.  NoSQL systems are faster because they do less.  We are seeing "SQL for big data" because, in part, organisations have noticed that developers are ending up doing joins in application code, as they do beyond simply putting bytes on web pages, to achieve their application goals. The result is slow applications even if the database is fast.



"NewSQL" is a consequence - a new generation of SQL systems written from scratch for the multi-machine, datacentre environment with all the issues of fault-tolerance and consistency that arise.



SPARQL is no different - if you do inherently fast things, like access a few triples by fixed subject URI, it's fast.  If you do inherently slow things, like look for a graph pattern without restriction on the graph nodes other than pattern, it's going to be slow.



No change in the laws of mathematics has occurred.