[
https://issues.apache.org/jira/browse/JENA-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143835#comment-17143835
]
Andy Seaborne commented on JENA-1918:
-------------------------------------
For this query:
{noformat}
SELECT ?item ?article
WHERE {
?item wdt:P31 wd:Q44. ##1
?article schema:isPartOf <https://en.wikipedia.org/>. ##2
?article schema:about ?item. ##3
}
{noformat}
The default "fixed reorder" optimizer will see ##1 and ##2 as equal weight (two
grounded terms) and ##3 as one grounded term.
It does not reorder amongst equal weight triple patterns so it will execute in
the order given.
Once it has chosen ##1, ##3 is not two grounded terms because ?item one is
bound at the point of execution. But being same weight as ##2, it will not
reorder. Arguably it should because of connectivity of patterns.
There is support for statistics based reordering in TDB (both) with a rule
based reorder function
[https://jena.apache.org/documentation/tdb/optimizer.html]
... but you need statistics or hand write the {{stats.opt}} file.
Pragmatically, the fixed weight is "good enough" and does not require
management of the statistics because, most of the time it does nearly as good,
often equal to, stats.
Note that the algorithm does not reorder unless the weights are different.
Writing:
{noformat}
{
?item wdt:P31 wd:Q44. ##1
?article schema:about ?item. ##3
?article schema:isPartOf <https://en.wikipedia.org/>. ##2
}
{noformat}
will link items to articles earlier.
> 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
> Assignee: Andy Seaborne
> Priority: Major
> Fix For: Jena 3.16.0
>
> Time Spent: 20m
> 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)
