on another note. while rolling out prototype builds with 2.7.1, one of our clients came back and complained about a query being excessively slow compared to before (like 10 times or more). The query was strangely written so I helped them change it to something more "natural" which made the query more acceptable in speed. It was still a little bit slower, but since that was in Tx, we can probably live with that. I need to get back to them to how much the comparison was. As I have mentioned before, we were still on jena 2.6.3 and associated libraries, but it puzzles me that Jena 2.7.1 does a worse job on this (admittedly badly written) query. Anyone has an idea why this could be?
This is the originally written query (fast on 2.6.3, extremely slow on 2.7.1) PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/> CONSTRUCT { ?s ?p ?o . } WHERE { GRAPH ?g { ?s ?p ?o . } ?doc jfs:resourceLocation ?g . FILTER ((?g = <documentUriGoesHere>) && (?s != ?doc)) } I made our client rewrite it to the following (fast on 2.6.3, fast on 2.7.1, if a bit slower than on 2.6.3) PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/> CONSTRUCT { ?s ?p ?o . } WHERE { GRAPH <documentUriGoesHere> { ?s ?p ?o . } ?doc jfs:resourceLocation <documentUriGoesHere> . FILTER (?s != ?doc) } So, the question is why Jena 2.6.3 was able to still do a good job with the former. I must admit that if I had seen the former and didn't know 2.6.3 was able to run this fast, I would always have thought that it would be slow because unless ARQ inlines the constraint on ?g, the only solution path I see is to essentially fetch the entire triple store and match the filter as you go. thanks Simon
