Hi Stefan,
Within each GRAPH block there is a light amount of optimization (picking
the first, most grounded tripe pattern; avoiding rdf:type) by default.
There isn't anything across GRAPH blocks.
TDB2 is the same as TDB1 in this regard (TDB2 is reworking the storage
and transactions, not the execution).
Andy
On 25/10/17 08:04, [email protected] wrote:
Are you using TDB?
This page:
https://jena.apache.org/documentation/tdb/optimizer.html
gives some info about how TDB uses statistics to reorder queries. To my
understanding (Andy can correct) graphs are not taken into account. TDB2
may be different...
For other cases-- the transactional in-memory store doesn't care very
much about this issue because hashmaps are used. I am not familiar
enough with the other in-memory implementations to comment.
ajs6f
Martynas Jusevičius wrote on 10/25/17 8:58 AM:
Maybe this article can help:
http://wwwconference.org/www2008/papers/pdf/p595-stocker1.pdf
It's about BGPs not graph patterns, but I guess selectivity still
applies.
On Wed, 25 Oct 2017 at 03.17, Dimov, Stefan <[email protected]> wrote:
Let’s consider the following JOIN:
SELECT $subj
FROM NAMED ng1
FROM NAMED ng2
{
GRAPH ng1 { $subj $pred0 $obj0 }
GRAPH ng2 { $subj $pred1 $obj1 }
}
My question is: Does the order of the clauses affect the performance?
Let’s say that ng1 is much bigger than ng2. If SPARQL applies the first
clause first and then the second clause over the set result of the first
one, then it makes sense to exchange their places.
Is that right?
Regards,
Stefan
