Perhaps this makes it more obvious - 9s to query a table of just 1.3M rows with ST_Intersects and 20ms using &&.<div><br></div><div><div>explain analyze select count(*) from wastac.t_tile_geometry where ST_Intersects(border, ST_GeographyFromText('SRID=4326;POLYGON((116.751709 -31.381779,116.883545 -32.676373,114.741211 -32.796510,114.796143 -31.316101,116.751709 -31.381779))'));</div>
<div> </div><div> Aggregate  (cost=364056.80..364056.81 rows=1 width=0) (actual time=9175.760..9175.761 rows=1 loops=1)</div><div>   ->  Seq Scan on t_tile_geometry  (cost=0.00..362993.14 rows=425463 width=0) (actual time=2164.049..9175.706 rows=95 loops=1)</div>
<div>         Filter: st_intersects(border, '0103000020E61000000100000005000000F8C610001C305D40B24CBF44BC613FC0D6E253008C385D40DE72F563935640C0DF1B430070AF5C40EE77280A</div><div>F46540C01EFCC401F4B25C409F3BC1FEEB503FC0F8C610001C305D40B24CBF44BC613FC0'::geography)</div>
<div> Total runtime: 9175.859 ms</div><div>(4 rows)</div><div><br></div><div><br></div><div>wastac=> explain analyze select count(*) from wastac.t_tile_geometry where ST_Intersects(border, ST_GeographyFromText('SRID=4326;POLYGON((116.751709 -31.381779,116.883545 -32.676373,114.741211 -32.796510,114.796143 -31.316101,116.751709 -31.381779))'));</div>
<div><br></div><div> Aggregate  (cost=364056.80..364056.81 rows=1 width=0) (actual time=8854.932..8854.933 rows=1 loops=1)</div><div>   ->  Seq Scan on t_tile_geometry  (cost=0.00..362993.14 rows=425463 width=0) (actual time=2017.629..8854.879 rows=95 loops=1)</div>
<div>         Filter: st_intersects(border, '0103000020E61000000100000005000000F8C610001C305D40B24CBF44BC613FC0D6E253008C385D40DE72F563935640C0DF1B430070AF5C40EE77280A</div><div>F46540C01EFCC401F4B25C409F3BC1FEEB503FC0F8C610001C305D40B24CBF44BC613FC0'::geography)</div>
<div> Total runtime: 8854.976 ms</div><div>(4 rows)</div><div><br></div><div><br></div><div>wastac=> explain analyze select count(*) from wastac.t_tile_geometry where border && ST_GeographyFromText('SRID=4326;POLYGON((116.751709 -31.381779,116.883545 -32.676373,114.741211 -32.796510,114.796143 -31.316101,116.751709 -31.381779))');</div>
<div><br></div><div> Aggregate  (cost=28.99..29.00 rows=1 width=0) (actual time=24.443..24.443 rows=1 loops=1)</div><div>   ->  Index Scan using t_tile_geometry_border_key on t_tile_geometry  (cost=0.00..28.97 rows=6 width=0) (actual time=9.952..24.407 rows=112 loops=1)</div>
<div>         Index Cond: (border && '0103000020E61000000100000005000000F8C610001C305D40B24CBF44BC613FC0D6E253008C385D40DE72F563935640C0DF1B430070AF5C40EE77280AF46540C</div><div>01EFCC401F4B25C409F3BC1FEEB503FC0F8C610001C305D40B24CBF44BC613FC0'::geography)</div>
<div> Total runtime: 24.681 ms</div><div><br></div></div><div><br></div><div><br><br><div class="gmail_quote">On 25 May 2010 22:45, Nicholas Bower <span dir="ltr"><<a href="mailto:nick@petangent.net">nick@petangent.net</a>></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 25 May 2010 22:35, Mark Cave-Ayland <span dir="ltr"><<a href="mailto:mark.cave-ayland@siriusit.co.uk" target="_blank">mark.cave-ayland@siriusit.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Nicholas Bower wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Neither of the ST_Intersects clauses below invoke index usage according to explain output, despite docs saying they should automatically be doing bbox on the index;<br>
</blockquote>
<br></div>
(cut)<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What's going on - the difference in total cost above proves to me the indexes are not being used.<br>
</blockquote>
<br></div>
I think you're missing the point here; the aim of the planner is to work out which join order will produce the query that executes in the shortest time. Therefore just because an index is present does not necessarily mean it is correct to use it.<br>


<br>
>From your first query (where the spatial index is not being used):<div><br>
Total runtime: 44744.241 ms<br>
<br></div>
>From your second query (where the spatial index is being used):<div><br>
Total runtime: 65952.140 ms<br>
<br></div>
So I'd say that this is working exactly as it should be, since the join order chosen by the planner has resulted in the shortest query time.<br></blockquote><div><br></div></div><div>A repeated explain analyze on the first query showed about 45s second time around (same).  However for the && version, second time around was just 2s (from 65s).</div>

<div><br></div><div>Saving 15s and losing caching seems like a bit of a false win no?</div><div><br></div></div>
</blockquote></div><br></div>