[postgis-devel] Try before you Buy

[Paul Ramsey]

I'm happy to keep the names the "same" where needed, subject to my  
public/private re-naming, coming soon. (I'll send a document to the  
list for review.)

ST_Accum will have the new behavior on the next commit, ST_Accum_Old  
will have the old behavior.

P.

On Jan 22, 2009, at 3:55 AM, Obe, Regina wrote:

> Paul,
>
> I hope we are not creating yet another aggregate function here, but I
> assume you are just doing this so we can test and compare.
>
> st_geometryarray(the_geom)
>
> Isn't this what ST_Accum is supposed to do in which case for the final
> version,  shouldn't you just replace the existing functionality of
> ST_Accum rather than introducing yet another term in my already  
> limited
> brain cells?
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of  
> Paul
> Ramsey
> Sent: Thursday, January 22, 2009 12:02 AM
> To: PostGIS Development Discussion
> Subject: [postgis-devel] Try before you Buy
>
> 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
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Paul Ramsey
pramsey at cleverelephant.ca
+1 250 885 0632