<br><br><div class="gmail_quote">On 25 May 2010 22:35, Mark Cave-Ayland <span dir="ltr"><<a href="mailto:mark.cave-ayland@siriusit.co.uk">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 class="im">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 class="im"><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 class="im"><br>
Total runtime: 44744.241 ms<br>
<br></div>
>From your second query (where the spatial index is being used):<div class="im"><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>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>