order of operations in SPARQL eval and execution

[nguyenm100]

Hey folks, I'm trying to use SAIL (3.7.4) against Janusgraph (lpg) and seeing an oddity wrt an order of operations. Perhaps I'm just misunderstanding...

If I write:

select ?c ?i where { 
  ?c rdfs:subClassOf+ "something";
      rdfs:subClassOf ?i .
}

I notice that the second statement is executed first inside the code (effectively: ?c rdfs:subClassOf ?i). I'm using the StrictEvaluationStrategy if that matters. If I rewrite the SPARQL as:

SELECT ?c ?i
WHERE { 

     ?c rdfs:subClassOf ?i .

     { select ?c where {
        ?c rdfs:subClassOf+ "something" .
     } }

}

I can control the ordering. The reason this matters is b/c I'm storing predicates as edges in JG and running a query like ?s rdfs:subClassOf ?i translates to a full scan of the edges in JG and thus very slow.

Anything I can do?

Thanks!

[abrokenjester]

The order in which the elements of a graph pattern are evaluated is determined by the query planner, which uses statistics and cost estimates provided by the underlying store implementation.

Try running a query explanation, this will tell you what numbers the planner uses for your particular query, and may give you a clue as to why it chooses the execution order it does.

I'm not very familiar with JanusGraph and don't know how you've been able to use RDF4J on top of it but at a guess I'd say that it lacks a store-specific extension of the EvaluationStatistics class which calculates these kinds of statistics. By default, a single pattern like that ?s subclassOf ?i will be considered cheaper than a recursive pattern like ?s subClassOf+ "something", so if that's not the case in this specific store, the EvaluationStatistics should be extended to inform the query planner of that.

[nguyenm100]

Thanks. It's actually a little more complicated than that since the statistics don't really take into account the existing set of statements that are left to execute and how many variables are bounded/unbounded at that time. Had to move up the chain in QueryJoinOptimizer to find the right spot. Seems to work now.