[postgis-devel] performance of force_collection()

[strk at refractions.net]

On Fri, Feb 25, 2005 at 12:30:37AM -0800, Ron Mayer wrote:
> strk at refractions.net wrote:
> > TYPE_SETTYPE and TYPE_GETTYPE both work on PG_LWGEOM.type,
> > so your patch is correct.
> >
> > The only problem is that using direct access of the serialized
> > form won't automatically add a bounding box cache, which is
> > a strategy we decided to engage for every function returning
> > a geometry (add a bbox cache if output geom is COMPLEX).
> 
> Well, I think force_2d() doesn't do this -- which is nice;
> because otherwise the overhead of mapserver's
>  force_collection(force_2d(the_geom))
> probably would have a performance overhead of 30-40%.  :)

force_2d does much more then force_collection:
	DETOAST
	for_each_geometry:
		deserialize
		change ZM flag
		serialize
	PG_LWGEOM_construct

> Is there a quick way of detecting the bounding box cache without
> deserializing the object?  Then the function could do an early
> exit only if it sees the bbox.

This can be done - see TYPE_HASBBOX macro.

> > The following query would return a MULTIPOINT with no BBOX cache:
> > SELECT summary(force_collection(dropbbox('SRID=4;MULTIPOINT(0 0, 1 1)')))
> > Is that acceptable for everybody ?
> 
> 
> I not, and if there's no other speedup, does anyone know
> a trick to make mapserver not add the force_collection(force_2d())
> wrapper for objects that are already 2D collections?   For that
> matter, why does it want 2d collections anyway?  I guess I
> try to find their mailing list and ask them...

For LWGEOM the asbinary() itself will call force_2d, which would be
a no-op for 2d input. Postgis-0.x would still require it if the goal
is size reduction.

Similarly I think force_collection would be useless as in PostGis-0.x it
made the input FLAT (a list of subobjects) while this is not true for
LWGEOM, so the mapserver connector would still require a more complex
parsing...

Finally, if you want to get the most speed mappostgis could completely
avoid asbinary() and use asEWKB() instead, which won't try to drop SRID
and enforce 2d representation. This would require the parser to understand
embedded SRID and ZM, and would make the connector tighter to postgis
version, so more easily breakable on postgis extensions changes.


--strk;

> 
> 
> > On Thu, Feb 24, 2005 at 02:20:39PM -0800, Ron Mayer wrote:
> >>...force_collection...taking 15-20% of the performance
> >>of many of my queries ...
> >>force_collection() is always deserializing and re-serializing
> >>the geometry...apparently be quite expensive on large geometries.
> 
> 
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel