Query Optimization

Support
1

Any suggestion on how to optimize this type of query.

it is very slow in stardog 4.2.3.

Apparently the chain from country -> state -> municipality is what makes it slow.

SELECT ?fa ?building ?fa_id ?net_floor_area ?actual_purpose ?country_id ?state_id ?municipality_id ?lat ?long ?building_id ?construction_year ?availability
WHERE {

?fa realestate:building_detail ?building .
?fa ontologies:id ?fa_id .
?fa realestate:net_floor_area ?net_floor_area .
?fa realestate:actual_purpose ?actual_purpose .
?building gn:locatedIn ?country .
?country ontologies:id ?country_id .
?country a geospatial:country .
?building gn:locatedIn ?state .
?state ontologies:id ?state_id .
?state a geotmp:state .
?building gn:locatedIn ?municipality .
?municipality ontologies:id ?municipality_id .
?municipality a geotmp:municipality .
?building wgs84:lat ?lat .
?building wgs84:long ?long .
?building ontologies:id ?building_id .
?building realestate:construction_year ?construction_year .

VALUES ?fa
{
http://geophy.io/functionalareas/131071
http://geophy.io/functionalareas/131072
http://geophy.io/functionalareas/131073
http://geophy.io/functionalareas/131074
}

}
2

Hi. Having the following is definitely not ideal, as it’s going to produce a lot of results that will just get discarded once other BGPs are evaluated.

?building gn:locatedIn ?country .
 ?building gn:locatedIn ?state .
 ?building gn:locatedIn ?municipality .

At a bare minimum, I would recommend that you rearrange the query a little to put ?country a geospatial:country ; ontologies:id ?country_id BEFORE ?building gn:locatedIn ?country, and likewise for ?state and ?municipality. That ought to restrict the pool of matches for each of the ?building gn:locatedIn X BGPs and should hopefully help at least a little bit.

3

You also might find the blog post "How to read Stardog Query Plans" helpful

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.