What is the average speed for running a shortest path query over a large city ? For Istanbul it takes about 3.5 seconds to find a path in my setup. I slightly modified sp_smart_directed function and using it right now but I am not sure if the speed is ok. If I reduce delta value for this function (which is limiting the region to be processed) operation is speeding up but it cannot find paths that exceeds the region.
If my query time is slow what is your suggestion on speeding things up? I added index for the_geom column. Is there anything to be done extra?
How large is your network?
I think you could do it faster, but it depends also on your hardware and you might also be able to make some changes in the postgresql configuration.
Ride the city for example is using pgRouting and the size of the cities should be comparable to Istanbul: http://www.ridethecity.com/
To improve speed you can check:
Indices for attributes used in your query
ID numbering (very high ID’s make it slow)
complicated cost calculation and joins between tables. If you have this, maybe you could pre-calculate some costs.
In general as less network data you load with your select as faster it is.
What is the average speed for running a shortest path query over a large city ? For Istanbul it takes about 3.5 seconds to find a path in my setup. I slightly modified sp_smart_directed function and using it right now but I am not sure if the speed is ok. If I reduce delta value for this function (which is limiting the region to be processed) operation is speeding up but it cannot find paths that exceeds the region.
If my query time is slow what is your suggestion on speeding things up? I added index for the_geom column. Is there anything to be done extra?
I have seen this mentioned several times, but never got an idea of what a very high ID is? What’s very high?
I have not tried this, but have considered using a smaller region initially and if a route is not found, jump to a bigger region and re-query, then perhaps fall back to an even bigger region before failing. If 90% of your routing will fit into the first region size then in general you will get much faster routing, and in the cases it fails, only slightly slower.
charles
On Feb 2, 2011, at 3:36 AM, Daniel Kastl wrote:
Hi Emre,
How large is your network?
I think you could do it faster, but it depends also on your hardware and you might also be able to make some changes in the postgresql configuration.
Ride the city for example is using pgRouting and the size of the cities should be comparable to Istanbul: http://www.ridethecity.com/
To improve speed you can check:
Indices for attributes used in your query
ID numbering (very high ID’s make it slow)
complicated cost calculation and joins between tables. If you have this, maybe you could pre-calculate some costs.
In general as less network data you load with your select as faster it is.
I have seen this mentioned several times, but never got an idea of what a very high ID is? What’s very high?
Best is when your ID’s start with 1 and not with something like 100000000001.
I have not tried this, but have considered using a smaller region initially and if a route is not found, jump to a bigger region and re-query, then perhaps fall back to an even bigger region before failing. If 90% of your routing will fit into the first region size then in general you will get much faster routing, and in the cases it fails, only slightly slower.
charles
On Feb 2, 2011, at 3:36 AM, Daniel Kastl wrote:
Hi Emre,
How large is your network?
I think you could do it faster, but it depends also on your hardware and you might also be able to make some changes in the postgresql configuration.
Ride the city for example is using pgRouting and the size of the cities should be comparable to Istanbul: http://www.ridethecity.com/
To improve speed you can check:
Indices for attributes used in your query
ID numbering (very high ID’s make it slow)
complicated cost calculation and joins between tables. If you have this, maybe you could pre-calculate some costs.
In general as less network data you load with your select as faster it is.
I was thinking that also and it seems a good solution.
Daniel:
my network is just about the same as newyork. (~297k link) I do not use join tables and use precalculated cost columns.
/emre
On Wed, Feb 2, 2011 at 4:04 PM, Charles Galpin <cgalpin@lhsw.com> wrote:
I have seen this mentioned several times, but never got an idea of what a very high ID is? What’s very high?
I have not tried this, but have considered using a smaller region initially and if a route is not found, jump to a bigger region and re-query, then perhaps fall back to an even bigger region before failing. If 90% of your routing will fit into the first region size then in general you will get much faster routing, and in the cases it fails, only slightly slower.
charles
On Feb 2, 2011, at 3:36 AM, Daniel Kastl wrote:
Hi Emre,
How large is your network?
I think you could do it faster, but it depends also on your hardware and you might also be able to make some changes in the postgresql configuration.
Ride the city for example is using pgRouting and the size of the cities should be comparable to Istanbul: http://www.ridethecity.com/
To improve speed you can check:
Indices for attributes used in your query
ID numbering (very high ID’s make it slow)
complicated cost calculation and joins between tables. If you have this, maybe you could pre-calculate some costs.
In general as less network data you load with your select as faster it is.
Than please check the indices of your main table. Do you have indices
created on geometry, gid, source, traget etc. columns?
How long is the time since you run 'vacuum full' on your database?