[
https://issues.apache.org/jira/browse/JENA-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141030#comment-17141030
]
Andy Seaborne commented on JENA-1918:
-------------------------------------
Semantically, order doesn't matter and the query transforms respect that.
Groundedness is the number of terms in a triple pattern that are concrete (not
variables) at the time of execution. Position and the exact term are factored
in - see {{ReorderFixed}} (rdf:type is special because {{(?x rdf:type
:SomeClass)}} can be very expensive.
It also tracks when a variable is bound earlier in a basic graph pattern which
counts as grounded.
Reordering happens below the query transform for triple patterns but not
*-paths or +-paths and only in adjacent blocks.
"/" and other forms are rewritten to expose triple patterns. Preserving
semantics of course!
{noformat}
?item wdt:P31/wdt:P279* wd:Q23397.
{noformat}
was rewritten to:
{noformat}
?item wdt:P31 ??P0 .
??P0 wdt:P279* wd:Q23397.
{noformat}
"??" are internally allocated variables that don't clash with any other
variable.
There is no reordering later because the basic graph pattern is the first
triple pattern. Pathe aren't considered.
In [PR 761|https://github.com/apache/jena/pull/761]
https://github.com/apache/jena/pull/761/files#diff-2ccd956247bbf33f05968610c5cee75eR101
If the object is a ground term and subject isn't, it will now chooses the other
order:
{noformat}
??P0 wdt:P279* wd:Q23397.
?item wdt:P31 ??P0 .
{noformat}
> Bad performance of path sequence and path*
> ------------------------------------------
>
> Key: JENA-1918
> URL: https://issues.apache.org/jira/browse/JENA-1918
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Affects Versions: Jena 3.15.0
> Reporter: Jonas Sourlier
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I want to execute the following SPARQL against my local Apache Jena (with
> preloaded Wikidata dump using TDB2):
> {code:java}
> PREFIX wd: <http://www.wikidata.org/entity/>
> PREFIX wdt: <http://www.wikidata.org/prop/direct/>
> PREFIX wikibase: <http://wikiba.se/ontology#>
> PREFIX p: <http://www.wikidata.org/prop/>
> PREFIX ps: <http://www.wikidata.org/prop/statement/>
> PREFIX pq: <http://www.wikidata.org/prop/qualifier/>
> SELECT ?item ?outflow ?drainageBasin ?coordinates ?elevation ?country
>
> WHERE {
> ?item wdt:P31/wdt:P279* wd:Q23397.
>
> OPTIONAL { ?item wdt:P201 ?outflow. }
> OPTIONAL { ?item wdt:P4614 ?drainageBasin. }
> OPTIONAL { ?item wdt:P625 ?coordinates. }
> OPTIONAL { ?item wdt:P2044 ?elevation. }
> OPTIONAL { ?item wdt:P17 ?country. }
> }
>
> ORDER BY ?item LIMIT 1 OFFSET 0
> {code}
> When run on query.wikidata.org (which uses Blazegraph), this query takes 26
> seconds to complete. Other queries run in about the same time as on
> query.wikidata.org.
> Apache Jena runs for several hours, using one CPU core and 3-4 GB of memory.
> Then it runs into some timeout (the timeout might be increased, but that's
> not the issue here).
> My question is, why is this so much slower than Blazegraph? Can this SPARQL
> be optimized to get a better performance? Can the query optimizer be tweaked
> to run this more efficiently?
> If not, then I consider this a bug, because the query itself should not
> generate such a big workload. If the query optimizer runs the
> {code:java}
> wdt:P31/wdt:P279*{code}
> predicate first, then limits it via the
> {code:java}
> ORDER BY ?item LIMIT 1 OFFSET 0{code}
> clause, there would be just one item for which it needs to execute the
> {code:java}
> OPTIONAL { ?item ... }{code}
> joins.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
