<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 3:12 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/25/2015 2:35 PM, Matt Geneau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
While looking at ways to speed up my routing queries with pg_trsp, I<br>
noticed my restrictions table is always being hit with sequential scans.<br>
I came across<br>
<a href="http://gis.stackexchange.com/questions/109156/pgrouting-what-index-should-have-the-restriction-table" rel="noreferrer" target="_blank">http://gis.stackexchange.com/questions/109156/pgrouting-what-index-should-have-the-restriction-table</a><br>
but unfortunately it has no answer.<br>
<br>
I tried guessing two indexes but they did not work. While looking<br>
through the trsp.c code on Github to see if that could point me in the<br>
right direction, I was unable to figure out how the restrictions are<br>
being loaded.<br>
<br>
Does anyone have any suggestions on the best way to index the<br>
restrictions table?<br>
</blockquote>
<br></span>
Hi Matt,<br>
<br>
The answer to this really has to do with what you need from the restrictions table for a given query.<br>
<br>
If you always pass the restrictions like: select * geom restrictions; then you will always do a full table scan and load all the restrictions regardless of whether or not you need them.<br>
<br>
So for example, if you are doing a bbox query on your edges, then it makes sense to only load the restrictions based on that same bbox. But since the restrictions tables does not have any geometry you need to fake it with a join against your edge table.<br>
<br>
So if your edges are selected like:<br>
    select * from edge_table where geom && bbox;<br>
<br>
Then you might consider a restriction query like:<br>
    select a.*<br>
      from restrictions a,<br>
           (select gid from edge_table where geom && bbox) b<br>
     where a.to_edge=b.gid;<br>
<br>
I'm using gid as the primary key on the edge table and that is also the values that are in the restrictions table.<br>
<br>
In the above example you what indexes on edge_table.gid, edge_table.geom and it might help to have restrictions.to_edge indexed also for the join.<br>
<br>
-Steve<br>
_______________________________________________<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" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-users</a></blockquote><div><br></div><div><br></div><div>For some reason I was thinking the restrictions were loaded after the route is generated, but of course they all need to be loaded beforehand in order to get a valid route.</div><div><br></div><div>Thanks your reply, your suggestions will definitely help.</div><div><br></div><div>Thanks,</div><div>Matt</div></div><br></div></div>