<div dir="ltr"><div>Hello</div><div>Today after 10h running the query stopped with this error</div><div>ERROR: could not extend file "base/552249/15383842.291": No space left on device</div><div>Stato SQL: 53100</div>
<div>Suggerimento: Check free disk space.</div><div><br></div><div>The space available was 280Gb.... so That file (doesn't exist now, because I think it was cancelled after query exit) was pretty big ;-)</div><div><br>
</div><div>Now I'm trying the left join method, let's see if it works.</div><div>The union of all 980000 polygons into one multipolygon will make a single record table, right?</div><div style>Isn't the complexity of the geometry contained into that single record "too complex" to be handled by the query?</div>
<div style><br></div><div style>Another solution that I am thinking is to add a field to these table that has the code of the original dxf extent.</div><div style>All features come from a set of more than 900 dxf that were loaded into a postgis db. all these 900 dxf were coded and I have a postgis tile vector table (dxf tileindex)..</div>
<div style>Then make a query with a join on a code field plus a geometry condition</div><div style>Do you think this will be a better performing method?</div><div style>Again thanks</div><div style><br></div><div style>bie</div>
<div style>pietro</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/7 Paragon Corporation <span dir="ltr"><<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Try,<br>
<div class="im"><br>
SELECT <a href="http://a.id" target="_blank">a.id</a>, a.layer, a.the_geom into newtable<br>
</div>  FROM my_first_table as a LEFT JOIN my_second_sable as b<br>
   ON ST_CoveredBy(a.the_geom, b.the_geom)<br>
WHERE b.gid IS NULL;<br>
<br>
<br>
Where b.gid is the primary key in your b table.<br>
<br>
Leo<br>
<a href="http://www.postgis.us" target="_blank">http://www.postgis.us</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:postgis-users-bounces@lists.osgeo.org">postgis-users-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:postgis-users-bounces@lists.osgeo.org">postgis-users-bounces@lists.osgeo.org</a>] On Behalf Of Pietro Rossin<br>
Sent: Tuesday, May 07, 2013 10:31 AM<br>
To: <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
Subject: [postgis-users] ST_CoveredBy() query run very very very slow<br>
<br>
Hello everybody<br>
I'm trying to select features from two spatial tables, geometry 2D.<br>
<br>
The first table is polylines from my whole area (984000 records).<br>
The second table is a polygon table, 970000 records. These polygons were<br>
created from the first table with an external tool (FME).<br>
<br>
Lots of polylines weren't converted to polygons and now I want to extract<br>
(into a new table) from the first table all the lines not converted to<br>
polygon to perform additional operations.<br>
<br>
The two table have indexes (gist) on the geom column<br>
<br>
So, my query is:<br>
<br>
SELECT <a href="http://a.id" target="_blank">a.id</a>, a.layer, a.the_geom into newtable<br>
  FROM my_first_table as a, my_second_sable as b<br>
  where<br>
  not ST_CoveredBy(a.the_geom, b.the_geom);<br>
<br>
Yesterdary I let it run for 72.000.000ms and then I had to stop it.<br>
I thought it was because of the Z values of all the geometries and the query<br>
was:<br>
<br>
SELECT <a href="http://a.id" target="_blank">a.id</a>, a.layer, a.the_geom into newtable<br>
  FROM my_first_table as a, my_second_sable as b<br>
  where<br>
  not ST_CoveredBy(st_force_2d(a.the_geom), st_force_2d(b.the_geom));<br>
<br>
Today It's running for 14.000.000ms and I have to stop it again...<br>
<br>
Why is this query so slow???<br>
My pc isd Windows XP 32b 4Gb ram, 2 opteron 252 processor.<br>
<br>
Thanks<br>
Pietro<br>
<br>
<br>
<br>
--<br>
View this message in context:<br>
<a href="http://postgis.17.x6.nabble.com/ST-CoveredBy-query-run-very-very-very-slow-t
p5003187.html" target="_blank">http://postgis.17.x6.nabble.com/ST-CoveredBy-query-run-very-very-very-slow-t<br>
p5003187.html</a><br>
Sent from the PostGIS - User mailing list archive at Nabble.com.<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
<br>
<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org">postgis-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br></div>