You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (Jira)" <ji...@apache.org> on 2021/05/17 15:05:00 UTC

[jira] [Comment Edited] (JENA-2107) RDF Star performance issue with non-concrete node triples

    [ https://issues.apache.org/jira/browse/JENA-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346211#comment-17346211 ] 

Andy Seaborne edited comment on JENA-2107 at 5/17/21, 3:04 PM:
---------------------------------------------------------------

{{tdbquery}} processing will be in SolverRX (one each for TDB1, TDB2).




was (Author: andy.seaborne):
{{tdbquery}} with be in SolverRX (one each for TDB1, TDB2).



> 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)