Btw, I got 15849 ms when I ran this query:<br><br>SELECT state,<br>
   SUM(ST_NPoints(the_geom)) As  numpointsbefore,<br>
     ST_NPoints(ST_Union_Fast(the_<div id=":1g0" class="ArwC7c ckChnd">geom)) As numpointsafter<br>
   FROM usstatebounds<br>
   GROUP BY state<br>
   ORDER BY state;<br><br>I was so excited to see unioncascade that I did not adjust my test server parameters.  Fyi, my server is on a 1.83 Ghz duo core laptop with 2 gigs of mem running Ubuntu Hardy Heron.  <br><br>This machine also has the latest postgresql, postgis, and geos installed.<br>
<br>GeoDB=# SELECT PostGIS_Full_Version();<br>                                  postgis_full_version<br>----------------------------------------------------------------------------------------<br> POSTGIS="1.4.0SVN" GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.1, 21 August 2008" USE_STATS<br>
(1 row)<br><br><br>How do I use _unite_garray_fast(st_geometryarray(the_geom)) with the usstatebounds?<br></div><br><br><div class="gmail_quote">On Wed, Jan 21, 2009 at 9:01 PM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">All the pieces of the new super-fast cascaded geometry are now in SVN.<br>
You'll need an absolutely fresh copy of GEOS to use them, but once you<br>
do, you can run something like this:<br>
<br>
aggtest=# select<br>
geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from<br>
sample_poly;<br>
       geometrytype --------------<br>
 MULTIPOLYGON<br>
(1 row)<br>
Time: 23267.905 ms<br>
<br>
<br>
note that<br>
 st_union() is still bound against the oldest implementation<br>
 st_union_fast() is bound against an implementation with slow<br>
aggregation but fast GEOS union<br>
 _unite_garray_fast(st_geometryarray()) is the only way to get the<br>
ultimate speed right now<br>
<br>
Unfortunately, it looks I'm going to need a special finalfunc for<br>
every single aggregate that takes in the internal pointer to the<br>
side-cache. That makes all the aggregates less pretty, since they<br>
won't use function(geometry[]) as their finalfunc anymore. The<br>
cleanest way would be to have those finalfuncs do little more than<br>
call other functions.<br>
<br>
Mark, is there a prescribed way to call postgresql functions (ones<br>
with (PG_FUNCTION_ARGS) as the argument) from other internal<br>
functions?<br>
<br>
Paul<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@postgis.refractions.net">postgis-devel@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
</blockquote></div><br>