<div dir="ltr">Hi Jonathan,<br><div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-17 13:18 GMT+01:00 Jonathan Moules <span dir="ltr"><<a href="mailto:jonathan-lists@lightpear.com" target="_blank">jonathan-lists@lightpear.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div style="font-size:10pt;font-family:verdana,arial,helvetica,sans-serif">Hi List,<br>I'm doing a simple ST_Intersects:<br><br>select geom<br>    from TABLENAME<br>    where <br>    ST_Intersects(geom, ST_GeomFromText('POLYGON((<wbr>260000 655000, 260000 660000, 270000 660000, 270000 655000, 260000 655000))', 27700))<br>    <br>TABLENAME does have a spatial index. But this query is still taking an exceptionally long time to run. The source table has about 62million features of relatively low complexity (no donuts, but a few self/ring-intersections). ANALYZE has been run.<br><br>This is the Explain:<br>Bitmap Heap Scan on polygon_active  (cost=36754.62..2156740.85 rows=403481 width=381)<br>  Recheck Cond: (geom && '<wbr>0103000020346C0000010000000500<wbr>00000000000000BD0F410000000030<wbr>FD23410000000000BD0F4100000000<wbr>4024244100000000C07A1041000000<wbr>004024244100000000C07A10410000<wbr>000030FD23410000000000BD0F4100<wbr>00000030FD2341'::geometry)<br>  Filter: _st_intersects(geom, '<wbr>0103000020346C0000010000000500<wbr>00000000000000BD0F410000000030<wbr>FD23410000000000BD0F4100000000<wbr>4024244100000000C07A1041000000<wbr>004024244100000000C07A10410000<wbr>000030FD23410000000000BD0F4100<wbr>00000030FD2341'::geometry)<br>  ->  Bitmap Index Scan on pg_geom_gix_active  (cost=0.00..36653.75 rows=1210444 width=0)<br>        Index Cond: (geom && '<wbr>0103000020346C0000010000000500<wbr>00000000000000BD0F410000000030<wbr>FD23410000000000BD0F4100000000<wbr>4024244100000000C07A1041000000<wbr>004024244100000000C07A10410000<wbr>000030FD23410000000000BD0F4100<wbr>00000030FD2341'::geometry)<br><br><br>From my interpretation of the above, the index scan is quick, but then the fine-detail confirmation is very-very slow. Reading around on the list archives, it probably shouldn't be this slow given this is a relatively recent version of PostGIS (version info below).<br>Is there a way to speed this up given my input geometry is a simple bounding box.<br></div></div></blockquote><div><br></div><div>To better understand the corresponding time of each execution node, you should run an EXPLAIN ANALYSE of the query. From what I can see here, the planner expects to do a lot of work during recheck condition where the exact intersection (i.e.<br></div><div>not between just bounding boxes) is performed: here it expects to inspect more than 2M of data blocks, filtering 400k rows from 1M rows.  <br></div></div><br></div><div class="gmail_extra">Could you attach here the output of an EXPLAIN (ANALYSE, BUFFER) of the query, if the execution does not take too long?<br><br></div><div class="gmail_extra">In any case, I'm posting here an useful link by Regina:<br><br><a href="http://postgis.net/2014/03/14/tip_intersection_faster/">http://postgis.net/2014/03/14/tip_intersection_faster/</a><br><br></div><div class="gmail_extra">About how to rewrite and improve queries when intersections are involved (some computation can be avoided for specific cases).<br clear="all"></div><div class="gmail_extra"><br></div><div class="gmail_extra">All the best,<br></div><div class="gmail_extra">Giuseppe.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span></span>Giuseppe Broccolo - 2ndQuadrant Italy
<br>PostgreSQL & PostGIS Training, Services and Support
<br><a href="mailto:giuseppe.broccolo@2ndQuadrant.it" target="_blank">giuseppe.broccolo@2ndQuadrant.it</a> | <a href="http://www.2ndQuadrant.it" target="_blank">www.2ndQuadrant.it</a>
</div></div></div></div>
</div></div></div>