Hi Andy, Thanks for the response. Your suggestion worked and the query completed in a similar time to the union graph approach. I'd tried moving the filter into the graph clause but not swapping the graph order.
I added that update on the documentation so if anyone else was having similar problems it might help. Do you still want me to create a JIRA for it? More generally, is there a page/section for tips on query writing to help optimisation? I searched but could only find description of TDB's optimisation functionality and extending query execution. I spent quite a while hunting for tips and trying different ways to influence the resolution order until I thought I'd try the union graph. Thanks, Greg -----Original Message----- From: Andy Seaborne <a...@apache.org> Sent: 19 June 2018 13:56 To: dev@jena.apache.org; Greg Albiston <greg_albis...@hotmail.com> Subject: Re: CMS diff: TDB Datasets Greg, Could you create a JIRA ticket for this please? It is something that looks addressable. The solution proposed (using union graph) is a bit specialised. Andy The query may be better if written (but the "..." may be making a difference.) GRAPH dataset:SmallB { ?b rdf:type my:BThing. ?b my:hasData ?bData. FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0 2.0"^^my:dataLiteral)) } GRAPH dataset:BigA { ?a rdf:type my:AThing. ?a noa:hasGeometry ?aData. } FILTER(my:filterFunction1(?bData, ?aData)) On 19/06/18 10:59, Greg Albiston wrote: > Clone URL (Committers only): > https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://j > ena.apache.org/documentation%2Ftdb%2Fdatasets.mdtext > > Greg Albiston > > Index: trunk/content/documentation/tdb/datasets.mdtext > =================================================================== > --- trunk/content/documentation/tdb/datasets.mdtext (revision 1833775) > +++ trunk/content/documentation/tdb/datasets.mdtext (working copy) > @@ -51,6 +51,51 @@ > ... > } > > +### Named Graphs & Filters > + > +Named graphs provide a convenient way to organise and store your data. > +However, be aware that in certain situations named graphs can make it > difficult for the query optimiser. > + > +For example, a query with the following structure took 29 minutes to > complete: > + > + SELECT ?b ... > + WHERE { > + > + GRAPH dataset:BigA { > + ?a rdf:type my:AThing. > + ?a noa:hasGeometry ?aData. > + ... > + } > + > + GRAPH dataset:SmallB { > + ?b rdf:type my:BThing. > + ?b my:hasData ?bData. > + ... > + } > + > + FILTER(my:filterFunction1(?bData, ?aData)) > + FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0 > + 2.0"^^my:dataLiteral) ) > + > + } > + > +The completion duration was reduced to 7 seconds by applying the global > TDB.symUnionDefaultGraph option (see above) to the dataset and modifying the > query as follows: > + > + SELECT ?b ... > + WHERE { > + > + ?a rdf:type my:AThing. > + ?a noa:hasGeometry ?aData. > + ... > + > + ?b rdf:type my:BThing. > + ?b my:hasData ?bData. > + ... > + > + FILTER(my:filterFunction1(?bData, ?aData)) > + FILTER(my:filterFunction2(?bData, "1.0 3.0, 4.0 > + 2.0"^^my:dataLiteral) ) > + > + } > + > ## Special Graph Names > > URI | Meaning >