Yeah, as expected, putting FILTER into OPTIONAL can help.
Just as a comment, the semantics is a bit different between
SELECT ?s ?o {
?s a :C .
OPTIONAL {
?s <p> ?o
}
FILTER(?o = "val")
}
and
SELECT ?s ?o {
?s a :C .
OPTIONAL {
?s <p> ?o
FILTER(?o = "val")
}
}
The first query evaluates to false in the FILTER if there is no ?o at
all, thus, ?s bindings might be dropped. In the second you'll always get
all ?s bindings. That is the reason why no optimizer will push the
filter into the OPTIONAL pattern.
Can you give some numbers on the current runtime of the query now? Did
you try the fulltext index?
I also saw your thread on SO where you tried GraphDB as well. Any
comparison numbers so far?
On 09.12.21 23:17, Matt Whitby wrote:
James was kind enough to spend some time talking me through the query.
My original query (which timed out) was:
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
select ?s ?name
where {
?s <http://www.historicengland.org.uk/data/schema/simplename/name> ?name .
OPTIONAL {?s <http://www.historicengland.org.uk/data/schema/county>
?county}.
OPTIONAL {?s <http://www.historicengland.org.uk/data/schema/district/>
?district}.
OPTIONAL {?s <http://www.historicengland.org.uk/data/schema/parish>
?parish}.
FILTER (CONTAINS(lcase(?county),"east sussex") || CONTAINS(
lcase(?district),"lewes") || CONTAINS( lcase(?parish),"lewes"))
}
limit 10
Putting the FILTER under each statement helped it immensely.
select ?s
where {
?s <http://www.historicengland.org.uk/data/schema/simplename/name>?name.
?s <http://www.historicengland.org.uk/data/schema/parish/> ?parish .
FILTER (CONTAINS(lcase(?parish),"lewes"))
?s <http://www.historicengland.org.uk/data/schema/district/> ?district .
FILTER (CONTAINS(lcase(?district),"lewes"))
?s <http://www.historicengland.org.uk/data/schema/county/> ?county .
FILTER (CONTAINS(lcase(?county),"east sussex"))
}
Putting back the OPTIONAL and running it a third time, slowed it down
(though not as badly as the first iteration).
M
