On 12.02.2016 00:04, Stas Malyshev wrote:
We basically have two choices: either we offer a
limited interface that only
allows for a narrow range of queries to be run at all. Or we offer a very
general interface that can run arbitrary queries, but we impose limits on time
and memory consumption. I would actually prefer the first option, because it's
more predictable, and doesn't get people's hopes up too far. What do you think?
That would require implementing pretty smart SPARQL parser... I don't
think it worth the investment of time. I'd rather put caps on runtime
and maybe also on parallel queries per IP, to ensure fair access. We may
also have a way to run longer queries - in fact, we'll need it anyway if
we want to automate lists - but that is longer term, we'll need to
figure out infrastructure for that and how we allocate access.
Restricting queries syntactically to be "simpler" is what we did in
Semantic MediaWiki (because MySQL did not support time/memory limits per
query). It is a workaround, but it will not prevent long-running queries
unless you make the syntactic restrictions really severe (and thereby
forbid many simple queries, too). I would not do it if there is support
for time/memory limits instead.
In the end, even the SPARQL engines are not able to predict reliably how
complicated a query is going to be -- it's an important part of their
work (for optimising query execution), but it is also very difficult.