<div dir="ltr"><div><div>The ticket :<br><a href="http://trac.osgeo.org/postgis/ticket/2860">http://trac.osgeo.org/postgis/ticket/2860</a><br><br></div><div>If fitting in memory, I would expect the 160k geom of the benchmark to be imported in less than 30 sec in grass, cgal and geos.<br>
</div><div>300 sec for Postgis Topology batch mode would be a good goal (reachable and nice achievement).<br><br></div>Cheers,<br></div>Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-30 11:56 GMT+02:00 Rémi Cura <span dir="ltr"><<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Almost a 10x factor, really nice !<br></div>Cheers,<br>Rémi-C<br></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">2014-07-30 11:38 GMT+02:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Jul 30, 2014 at 11:29:00AM +0200, Sandro Santilli wrote:<br>
<br>
> There's a reference dataset produced some time ago by a user who resulted<br>
> in a fix making topology creation much faster:<br>
> <a href="http://lists.osgeo.org/pipermail/postgis-devel/2014-January/024078.html" target="_blank">http://lists.osgeo.org/pipermail/postgis-devel/2014-January/024078.html</a><br>
><br>
> I still have a couple of diagrams showing population time before/after<br>
> that are waiting for a blog post that I never find the time to write...<br>
<br>
</div>Just a sneak preview of the blog post that might never be written<br>
<br>
Queries:<br>
<br>
 SELECT ST_CreateTopoGeo('million_poly_topo1', ST_Collect(geom))<br>
 FROM ( SELECT geom from million_poly_topo1 order by gid limit 160000) as f;<br>
<br>
 SELECT TopoGeo_addPolygon('million_poly_topo1', ST_GeometryN(geom,1))<br>
 FROM ( SELECT geom from million_poly_topo1 order by gid limit 160000) as f;<br>
<br>
Output topology has:<br>
<br>
 160167 nodes, 160167 edges, 160167 faces<br>
<br>
Times:<br>
<br>
 a: before starting<br>
 b: Ensure face splitting algorithm uses the edge index (#2610)<br>
 c: Drop all calls to geometry::text during topology population (#2616)<br>
<br>
      ST_CreateTopoGeo     TopoGeo_addPolygon<br>
    +-------------------+--------------------+<br>
 a  |    38352283.535   |    38375126.950    |<br>
 b  |    12088554.776   |     9644736.277    |<br>
 c  |    11963757.923   |     4984225.402    |<br>
<br>
I've a table with more numbers, with limits from 5000 to 160000.<br>
The index change would make another configuration (d, I guess).<br>
<br>
Please please please file the ticket, maybe referencing this thread<br>
and #2610 and #2616 as I'd really love to grow the optimizations further<br>
<div><div><br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div>