<br><br><div class="gmail_quote">On Wed, Aug 3, 2011 at 2:39 PM, Daniel Kastl <span dir="ltr">&lt;<a href="mailto:daniel@georepublic.de">daniel@georepublic.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Wed, Aug 3, 2011 at 9:03 PM, Martin Lee <span dir="ltr">&lt;<a href="mailto:martinchlee@gmail.com" target="_blank">martinchlee@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


[Small note: The author of this question is familiar with PostGIS, but is not familiar with C language]<br><br>I have a &#39;ways&#39; table in PostGIS consisting of about 90,000 ways. When I do a pgRouting shortest path query it takes about 2,5 seconds to get the result.<br>


</blockquote><div><br></div></div><div>This is really not many ways. It should be a lot faster.</div><div><ul><li>Did you check your tables have indices?</li></ul></div></div></blockquote><div><br>All the tables have indices. Are there any special requirements to particular tables to have indices? <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><ul><li>Do you use bounding boxes not to load all the data (but in your case it&#39;s such a small number of ways that even loading all shouldn&#39;t take long.)</li>


</ul></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>I was pretty unsatisfied with it (I would like it to be about 1 second for my imagined user) so I tried to do a &#39;select * from ways&#39; query in psql with \timing enabled. It took 3 seconds to respond. When I did &#39;select name, length, x1, y1, x2, y2 from ways&#39; (that is all needed to build a graph in my opinion) it took even more - 4 seconds to respond.<br>



<br>Based on that, I assume that pgRouting&#39;s SQL queries are somehow optimized. <br><br>The questions:<br>1. Is it possible to improve the speed of pgRouting queries?<br></blockquote><div><br></div></div><div>The bottleneck is the number of ways you select from the table. </div>


<div>You can improve your speed by selecting less road links.</div></div></blockquote><div><br>I am sorry, but I don&#39;t really understand what &#39;road links&#39; mean in pgRouting parlance. There are vertices which are built from OSM nodes, there are ways which are extracted from OSM multi-line ways. How road links are represented and in which table?<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>Anything else (like routing algorithms for example) might affect calculation time, but this is only very little compared to the data volume to load.</div>


<div><br></div><div>One thing you could check is how your way ID&#39;s look like. Lower ID&#39;s are better, so you may want to renumber them if there are large ID&#39;s and large gaps between them. You can create a new id attribute for that.</div>
</div></blockquote><div><br>Is the column name &#39;gid&#39;? By the way, why is it called &#39;gid&#39; and not &#39;id&#39;?<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">

<div><br></div><div>Daniel</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">2. How is the actual shortest path calculation done? Is it anything like the following:<br>



- Load the whole ways/edges table into memory with one &#39;select * from ways&#39;;<br>- Build a graph from that;<br>- Apply a C-based shortest path algorithm to the graph;<br>- Return a result into psql server?<br><br>


<br>
Can any of these steps be improved anyhow?<br><br>Thank you!<br>
<br></div>_______________________________________________<br>
Pgrouting-users mailing list<br>
<a href="mailto:Pgrouting-users@lists.osgeo.org" target="_blank">Pgrouting-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-users</a><br>
<br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG &amp; Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66, 99, 171)" target="_blank">daniel.kastl@georepublic.de</a><br>


Web: <a href="http://georepublic.de/" style="color:rgb(66, 99, 171)" target="_blank">http://georepublic.de</a></span><br>
</font><br>_______________________________________________<br>
Pgrouting-users mailing list<br>
<a href="mailto:Pgrouting-users@lists.osgeo.org">Pgrouting-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-users</a><br>
<br></blockquote></div><br>