[pgrouting-users] Newbie pgr_dijkstra performance question
Andrew Harfoot
ajph at geodata.soton.ac.uk
Fri Jan 24 08:59:38 PST 2014
Thanks very much for the swift responses and clear explanations. I'll
explore the BBOX filtering in more detail.
Cheers,
Andy
On 24/01/2014 16:21, Stephen Woodbridge wrote:
> On 1/24/2014 10:45 AM, Andrew Harfoot wrote:
>> Hi there,
>>
>> I have been looking at pgrouting in the past week, and have a test
>> installation using the following:
>>
>> Win7 64bit on an i7 processor with 8Gb RAM
>> Postgres 9.2.4 64bit
>> Postgis 2.0.3-2 64bit
>> pgrouting 2.0 64bit
>>
>> My test dataset is the Ordnance Survey Meridian roads dataset for Great
>> Britain which has ~1.2 million edges.
>>
>> I can successfully use the pgr_dijkstra function to generate routing,
>> but the performance seems a little slow. My test route takes around 10
>> seconds to return in pgAdminIII, and so my first question is whether
>> this is about what I should be expecting. I am not pre-filtering the
>> ways being passed to pgr_dijkstra using a bounding box or such like
>
> You should definitely use the bbox filtering of the ways, otherwise
> you are loading ALL ways for every query. The way pgrouting works is
> on each query, it reads the ways, builds a graph and solves the graph
> to give you your results. The smaller the graph and number of ways
> need the faster it is.
>
>> The second question is that whilst exploring the performance, I removed
>> the indexes that pgr_createtopology had built on the source and target
>> fields of the road data. To my surprise, this had no effect whatsoever
>> on the performance of pgr_dijkstra, and after rebuilding them and
>> looking at the index stats in pgAdminIII, this is reporting no usage of
>> the indexes at all (I did rerun some routing queries after rebuilding
>> the indexes!). Again, is this expected?
>
> Those indexes are not used when computing a route, they are only used
> to compute the topology and potentially during any post-processing you
> might decide to do to analyze the resultant path.
>
>> It seems to contradict the
>> recommendation to build the indexes in the pgr workshop:
>> http://workshop.pgrouting.org/chapters/topology.html#add-indices
>
> Right, needed to compute the topology.
>
> pgRouting is extremely flexible because we dynamically build the graph
> so we can easily do things like change the runtime solutions based on
> integrating traffic data, or eliminating edges in a disaster area, or
> changing the vehicle type or road preferences, etc. This comes at the
> cost of being the fastest possible solution.
>
> If performance is more important than this flexibility, then you might
> want to look at Project-OSRM and osrm-tools as an alternative or to
> augment pgRouting.
>
> Thanks,
> -Steve
>
>> Any thoughts appreciated,
>>
>> Cheers,
>>
>> Andy
>>
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
--
Andy Harfoot
GeoData Institute
University of Southampton
Southampton
SO17 1BJ
Tel: +44 (0)23 8059 2719
Fax: +44 (0)23 8059 2849
www.geodata.soton.ac.uk
More information about the Pgrouting-users
mailing list