Thanks for all the suggestions.<div>I first thought about doing the simplify, but after some reconsideration I realized that this would change the geometry of the country borders, and Area measurements might be wrong.</div>
<div><br></div><div>Then i tried the query without the ST_Intersection and only the conditional ST_Intersects. </div><div>This completed in 87 seconds, so this was very fast compared to 40-50 minutes per year.</div><div><br>
</div><div>I also tried the UNION ALL suggestion by Nicklas which had almost similar performance as the original query. I will test this some more to see whether i can save some time.</div><div><br></div><div>My guess is that the calculation time required to create the new intersected geometry is what takes so long, and this is probably something i need to accept (or get more cpu power :)</div>
<div><br></div><div>Andreas<br><div><br><div class="gmail_quote">2011/3/9 Mark Cave-Ayland <span dir="ltr"><<a href="mailto:mark.cave-ayland@siriusit.co.uk">mark.cave-ayland@siriusit.co.uk</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 08/03/11 17:01, Andreas Forų Tollefsen wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After a suggestion from pgsql_performance i tried with ST_Simplify to<br>
speed things up.<br>
However this gives me a:<br>
NOTICE: ptarray_simplify returned a <2 pts array<br>
<br>
Then server connection terminates.<br>
<br>
Like this:<br>
<br>
SELECT ST_Intersection(priogrid_land.cell,<br>
ST_Simplify(cshapeswdate.geom,0.1)) AS geom,<br>
priogrid_land.gid AS divider, gwcode, gwsyear, gweyear, startdate,<br>
enddate, capname, caplong, caplat, col, row, xcoord, ycoord<br>
FROM priogrid_land, cshapeswdate WHERE ST_Intersects(priogrid_land.cell,<br>
ST_Simplify(cshapeswdate.geom,0.1)) AND cshapeswdate.gwsyear <=1946 AND<br>
cshapeswdate.gweyear >=1946 AND cshapeswdate.startdate <= '1946/1/1';<br>
</blockquote>
<br></div>
Yup that's a bug related to the new code in trunk - I think we've already got something similar filed in the bug tracker. This is probably going to require a Paul to take a look at it.<br>
<br>
<br>
ATB,<br>
<br>
Mark.<br><font color="#888888">
<br>
-- <br>
Mark Cave-Ayland - Senior Technical Architect<br>
PostgreSQL - PostGIS<br>
Sirius Corporation plc - control through freedom<br>
<a href="http://www.siriusit.co.uk" target="_blank">http://www.siriusit.co.uk</a><br>
t: +44 870 608 0063<br>
<br>
Sirius Labs: <a href="http://www.siriusit.co.uk/labs" target="_blank">http://www.siriusit.co.uk/labs</a></font><div><div></div><div class="h5"><br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br></div></div>