Query Optimization

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
}

}

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.

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

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