[
https://issues.apache.org/jira/browse/JENA-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Bühmann updated JENA-2107:
---------------------------------
Description:
the following graph pattern is not evaluated efficiently (results in full-scan
per binding) because the second triple pattern doesn't take advantage of the
bindings generated by evaluation of the first one:
{code:java}
?s <p> ?o .
<< ?s <p> ?o >> <p2> ?v .
{code}
A possible fix would be to adapt the method {{rdfStarTripleSub()}} in class
[SolverRX3.java|https://github.com/apache/jena/blob/2efff8a00b4ffa82751cf46c8a3fed84b6ff3090/jena-arq/src/main/java/org/apache/jena/sparql/engine/main/solver/SolverRX3.java#L63-L71]
by changing the beginning to
{code:java}
private static Iterator<Binding> rdfStarTripleSub(Binding input, Triple
xPattern, ExecutionContext execCxt) {
Triple tPattern = Substitute.substitute(xPattern, input);
{code}
We went from 75s for a very small dataset (50k triples) to near instant
response times.
If this fix is correct and doesn't break anything, it might be the same way to
fix for its quads counterpart in {{SolverRX4}} class.
Note, for tdbquery, this seems to be evaluated at a different place? At least,
we couldn't find any performance improvement, it's still horribly slow.
was:
the following graph pattern is not evaluated efficiently (results in full-scan
per binding) because the second triple pattern doesn't take advantage of the
bindings generated by evaluation of the first one:
{code:java}
?s <p> ?o .
<< ?s <p> ?o >> <p2> ?v .
{code}
A possible fix would be to adapt the method {{rdfStarTripleSub()}} in class
[SolverRX3.java|https://github.com/apache/jena/blob/2efff8a00b4ffa82751cf46c8a3fed84b6ff3090/jena-arq/src/main/java/org/apache/jena/sparql/engine/main/solver/SolverRX3.java#L63-L71]
by changing the beginning to
{code:java}
private static Iterator<Binding> rdfStarTripleSub(Binding input, Triple
xPattern, ExecutionContext execCxt) {
Triple tPattern = Substitute.substitute(xPattern, input);
{code}
We went from 75s for a very small dataset (50k triples) to near instant
response times.
If this fix is correct and doesn't break anything, it might be the same way to
fix for its quads counterpart in {{SolverRX4}} class
> RDF Star performance issue with non-concrete node triples
> ---------------------------------------------------------
>
> Key: JENA-2107
> URL: https://issues.apache.org/jira/browse/JENA-2107
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Affects Versions: Jena 3.17.0, Jena 4.0.0
> Reporter: Lorenz Bühmann
> Priority: Critical
> Fix For: Jena 4.1.0
>
>
> the following graph pattern is not evaluated efficiently (results in
> full-scan per binding) because the second triple pattern doesn't take
> advantage of the bindings generated by evaluation of the first one:
> {code:java}
> ?s <p> ?o .
> << ?s <p> ?o >> <p2> ?v .
> {code}
> A possible fix would be to adapt the method {{rdfStarTripleSub()}} in class
>
> [SolverRX3.java|https://github.com/apache/jena/blob/2efff8a00b4ffa82751cf46c8a3fed84b6ff3090/jena-arq/src/main/java/org/apache/jena/sparql/engine/main/solver/SolverRX3.java#L63-L71]
> by changing the beginning to
> {code:java}
> private static Iterator<Binding> rdfStarTripleSub(Binding input, Triple
> xPattern, ExecutionContext execCxt) {
> Triple tPattern = Substitute.substitute(xPattern, input);
> {code}
> We went from 75s for a very small dataset (50k triples) to near instant
> response times.
> If this fix is correct and doesn't break anything, it might be the same way
> to fix for its quads counterpart in {{SolverRX4}} class.
>
> Note, for tdbquery, this seems to be evaluated at a different place? At
> least, we couldn't find any performance improvement, it's still horribly slow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
