You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 15, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: pgrouting/pgrouting-speedups.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -216,7 +216,7 @@ If we rerun our query, we'll see yet another speed up: I was able to cut it from
216
216
217
217
Now the tweaks and tricks we have shown so far have only been tested on one route, but as we were delving into this topic, we wondered how these speedups compare across routes with different lengths. So we computed some hundred routes between random points in Northern California with different lengths and plotted the execution times for each route, and at every stage described above (baseline, fixed cost, etc.). You can find the **jupyter notebook [here](https://github.com/gis-ops/tutorials/blob/master/pgrouting/compare_computation_times.ipynb)**
218
218
219
-
![Query execution times](./static/img/pgr_exec_times.jpg"OpenStreetMap data in its pure form is not routable")
219
+
![Query execution times](https://raw.githubusercontent.com/gis-ops/tutorials/master/pgrouting/static/img/pgr_exec_times.jpg"OpenStreetMap data in its pure form is not routable")
220
220
221
221
As you can see, computing the cost on the fly is pretty much the worst thing you can do in terms of execution time. Even for the shortest query, the cost is computed for all 3 million edges in our edges table and so always takes about 20 seconds in our example queries. And although it is wildly inefficient, this practice keeps appearing in many `pgr_dijkstra` examples given on StackExchange and other forums and thereby persists. But even with a fixed cost, the execution times do not differ across different route lengths. This makes sense, as we are still selecting all 3 million edges as an input for dijkstra's algorithm. Only when using the bbox intersecting, indexing and clustering techniques, we really see performance improvements for small to mid-range distance routes, although the speedups from the clustering appear to be minimal. However, at distances greater than 500km, even with our clustering techniques, our queries take between 5 and 10 seconds to compute, which makes sense as the bounding box speed up is now probably covering the entire region.
0 commit comments