[postgis-devel] Try before you Buy

[Bob and Deb]

Replying to myself :-)  I figured it out.  I used this query and got 12661
ms:

SELECT state,
  SUM(ST_NPoints(the_geom)) As  numpointsbefore,
    ST_NPoints(_unite_garray_fast(st_geometryarray(the_geom))) As
numpointsafter
  FROM usstatebounds
  GROUP BY state
  ORDER BY state;



On Thu, Jan 22, 2009 at 12:28 AM, Bob and Deb <bobdebm at gmail.com> wrote:

> Btw, I got 15849 ms when I ran this query:
>
> SELECT state,
>   SUM(ST_NPoints(the_geom)) As  numpointsbefore,
>     ST_NPoints(ST_Union_Fast(the_geom)) As numpointsafter
>   FROM usstatebounds
>   GROUP BY state
>   ORDER BY state;
>
> 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.
>
> This machine also has the latest postgresql, postgis, and geos installed.
>
> GeoDB=# SELECT PostGIS_Full_Version();
>                                   postgis_full_version
>
> ----------------------------------------------------------------------------------------
>  POSTGIS="1.4.0SVN" GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.1, 21 August
> 2008" USE_STATS
> (1 row)
>
>
> How do I use _unite_garray_fast(st_geometryarray(the_geom)) with the
> usstatebounds?
>
>
> On Wed, Jan 21, 2009 at 9:01 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
>
>> All the pieces of the new super-fast cascaded geometry are now in SVN.
>> You'll need an absolutely fresh copy of GEOS to use them, but once you
>> do, you can run something like this:
>>
>> aggtest=# select
>> geometrytype(_unite_garray_fast(st_geometryarray(the_geom))) from
>> sample_poly;
>>       geometrytype --------------
>>  MULTIPOLYGON
>> (1 row)
>> Time: 23267.905 ms
>>
>>
>> note that
>>  st_union() is still bound against the oldest implementation
>>  st_union_fast() is bound against an implementation with slow
>> aggregation but fast GEOS union
>>  _unite_garray_fast(st_geometryarray()) is the only way to get the
>> ultimate speed right now
>>
>> Unfortunately, it looks I'm going to need a special finalfunc for
>> every single aggregate that takes in the internal pointer to the
>> side-cache. That makes all the aggregates less pretty, since they
>> won't use function(geometry[]) as their finalfunc anymore. The
>> cleanest way would be to have those finalfuncs do little more than
>> call other functions.
>>
>> Mark, is there a prescribed way to call postgresql functions (ones
>> with (PG_FUNCTION_ARGS) as the argument) from other internal
>> functions?
>>
>> Paul
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090122/8db8e8a1/attachment.html>