[geos-devel] GEOSGetCoordinates() and performance (postgis bug fix)

[chodgson at refractions.net]

The way postgres handles user-defined aggregate functions is what is limiting 
you. The problem is that aggregates are designed to use a "one-at-a-time" 
approach to aggregating, which means that at each step of the process you must 
have "geom UNION geom = geom". 

Clearly, if there was a postgres type which was a serialized GEOS gemetry (call 
it type geos_geom) then we could write a geos_geom_union function which was 
geos_geom UNION geos_geom = geos_geom, and as long as the serialization can be 
done quickly (and is even possible?) then a faster union aggregate could result 
from a query like:

SELECT geos_geom_to_geom( geos_geom_union( geom_to_geos_geom( the-geom ) ) ) 
FROM the_table GROUP BY class_id;

I don't know enough C/C++ to know if such a serialization of a GEOS geometry is 
possible, or fast... but if so, this would probably do it.

It could even be possible to re-write all of the geos functions to accept 
geos_geom objects, and have standard geom object be auto-typecast into 
geos_geom objects (using the "geom_to_geos_geom()" function, of course)... then 
it would be easy to cache the geos objects in between processing stages - who 
knows how big they might be... again, if this is even possible.

Chris

Quoting strk <strk at keybit.net>:

> dblasby wrote:
> > Whenever I call the getCoordinates() function, I immediately make a copy
> > of the list by converting it from the GEOS coordinates to PostGIS POINT3Ds.
> >
> > So, feel free to have all the Postgis GetCoordinates() access read-only
> > version.
> 
> I've made a specialized POINT3D-array-from-Polygon function using read-only
> direct access to internal Polygon's LinearRings. Speed up is to evaluate
> but personally I can not really appreciate it...
> 
> > UNIT probably spending a lot of time building Postgis and GEOS geometries.
> >
> > 1. start with 2 input postgis geometrys
> > 2. convert them to GEOS (O(n) where n=# of subcomponents)
> > 3. run union
> > 4. convert back to postgis (O(n) where n=# of subcomponents)
> > 5. start again at step #1
> >
> > As you can see there possibly O(n^2) constructions (and certainly O(n^2)
> > point copies).
> >
> > If you take an input dataset of disjoint polygons, you'll see this is
> > O(n^2) in terms of geometry convertions and copying.
> 
> Do you think defining an ad-hoc postgresql type will give it a burst ?
> 
> --strk;
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
>