On 26/08/16 11:35, Rob Vesse wrote:
To try to answer the question about your specific query it’s
difficult without knowing more about the nature of the data, in your
case how many named graphs are in the database?
One thing that jumps out at me is that you use the GRAPH operator in
your query. That operator essentially requires that a query engine
applies your inner query to every single graph in your database. In
practice ARQ Will try to do something a bit more efficient than that
but this is not guaranteed.
TDB does all the graphs at the same time if it can. Property paths can
stop this but basic graph patterns + GRAPH ?var is done as quad table
accesses.
Ditto for TIM.
(It's only the general purpose in-memory dataset where you can put any
graph in from any source that has to loop.)
Your inner query uses a lots of property paths and so is potentially
quite expensive. As a first step I would suggest changing * to + if
you can as that will avoid having to match the Zero length path which
while quite simple for your case can be very expensive for more
generic property paths.
And has been speed up recently (after the last release I'm afraid, post
Jena 3.1.0 (Fuseki 2.4.0)) JENA-1195
How long are the skos:narrower* chains?
Mikael - are you able to try out a SNAPSHOT build?
Secondly if you are able to limit the number of graphs that are under
consideration you may be able to substantially improved performance.
One way to do this would be to place a pattern prior to the GRAPH
operator that restricts the values of the ?graph variable. ARQ
should then be able to use that information to restrict which graphs
in the database it scans.
Rob
Andy
