If you use TDB as backend, you could run
tdbquery --explain --loc=PATH_TO_YOUR_DB "YOUR QUERY HERE" and share the output here? Also, a stats file does exist for your dataset? On 21.01.20 21:37, Élie Roux wrote: > I'm starting to see what's going on, it seems that the optimization > (according to sparql.org) gives > > 13 (disjunction > 14 (assign ((?resp skos:altLabel)) > 15 (bgp > 16 (triple bdr:G844 ?rel ?res) > 17 (triple ?res rdf:type :Place) > 18 (triple ?res skos:altLabel ?reso) > 19 )) > 20 (assign ((?resp skos:prefLabel)) > 21 (bgp > 22 (triple bdr:G844 ?rel ?res) > 23 (triple ?res rdf:type :Place) > 24 (triple ?res skos:prefLabel ?reso) > 25 )) > [...] etc. > > instead of > > 13 (filter (in ?resp skos:altLabel skos:prefLabel skos:placeEvent > :placeLat :placeLong :placeType :placeLocatedIn owl:sameAs > tmp:entityScore) > 14 (bgp > 15 (triple bdr:G844 ?rel ?res) > 16 (triple ?res rdf:type :Place) > 17 (triple ?res ?resp ?reso) > 18 )))) > > > which I believe might result in a penalty... although frankly, I still > can't understand how a very basic bgp like > > 21 (bgp > 22 (triple bdr:G844 ?rel ?res) > 23 (triple ?res rdf:type :Place) > 24 (triple ?res skos:prefLabel ?reso) > > can take 100ms. Is there a way to tune the optimization level of > features in queries or at the Fuseki level? > > Best,
