[postgis-devel] [PostGIS] #76: ST_DumpPoints - I think we said we would add to TODO

[PostGIS]

#76: ST_DumpPoints - I think we said we would add to TODO
--------------------------+-------------------------------------------------
  Reporter:  robe         |       Owner:  robe         
      Type:  enhancement  |      Status:  assigned     
  Priority:  medium       |   Milestone:  postgis 1.5.0
 Component:  postgis      |     Version:  trunk        
Resolution:  accepted     |    Keywords:               
--------------------------+-------------------------------------------------
Comment (by yabo):

 Replying to [comment:8 robe]:
 > Yabo -- if its any help.  Its not so much that C is a better language
 than
 > plpgsql.  Its not really.  Its just the interaction between PostgreSQL
 and the
 > PostGIS c code that is the main problem.  I think the issue is that each
 call
 > to ST_GeometryN etc. incurs a memcopy penalty where as when done in C
 (as is
 > the case with ST_Dump -- the same geometry object is reused).

 I see. So it could be easier to develop some low-level C functions that
 allows
 more direct access to geometries ? Would it be possible to write a
 GeometryN
 function that doesn't copy the geometry ?

 > If you replace your ST_GeometryN calls with ST_Dump -- you'd probably
 also get
 > much better performance but would run into performance issues when you
 get to
 > many points in a single geom.

 Very nice improvement indeed ! Though it limits the depth to 32 (as
 defined in
 the source code of ST_Dump) the performance improvement is quite nice :

 31 nested collections of 100 multipolygons each :
 with ST_GeometryN : 3700 ms
 with ST_Dump : 550 ms

 I've then tested to dump the points of a linestring containing 10 000
 points and
 it takes ~ 3 seconds. It doesn't seem to scale linearly as with 50 000
 points it
 takes up to ~ 73 seconds...

 However I've attached the new code using ST_Dump rather than ST_GeometryN.

 > Actually if we solved that more annoying issue -- we could probably get
 way
 > better performance with plpgsql/sql functions which are far easier to
 write
 > than C functions.

 It would be great.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/76#comment:9>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS