I am using pgrouting on a postgis database created through osm2pgrouting. It performs very good on a limited dataset (3.5k ways, all shortest path A* searches < 20 ms).
However since I have imported a bigger bounding box (122k ways) from europe.osm the performance went down a lot (a shortest path costs around 900ms).
I would think that using A* most of those edges will never be visited as they are out of the way.
What I have done so far in an attempt to improve the speed:
- Put an index on the geometry column (no noticeable effect)
- Increased my memory from 8GB to 16GB
- Change the postgresql memory settings (shared_buffers, effective_cache_size) from (128MB, 128MB) to (1GB, 2GB) (no noticeable effect)
I have a feeling that most of the work is being done in the C Boost library where the graph is being made so optimizing postgresql will not give me much better results. As I do minor changes to the set of rows I select for A* for every search I am a bit afraid that the boost library cannot cache my graph and has to rebuild all the 122k edges every time (even though it will only use a very limited subset every query). And I have no idea how much is spent doing that compared to the actual shortest path search.
Does any of you use pgrouting on a 122k or greater OSM dataset? What performance should I expect? What settings affect the performance most?