[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 robe):

 Relevant NOTE form Yabo:
 On 08/05/09 14:47, Maxime van Noppen wrote:
 > Thanks. However Robe (cf ticket) and you are right, there is a
 > scalability issue. For the sake of the test I've implemented the ST_Dump
 > function in plpgsql with a recursive call (as my_ST_DumpPoints is) and
 > in some very bad cases it's very slow. For example I've tested to dump a
 > geometry containing 100 nested GEOMETRYCOLLECTION containing each 10
 > multipolygons. ST_Dump runs in 35ms whereas my_ST_Dump runs in 230ms
 > (sorry if I'm stating obvious things here, I'm quite new to the postgis
 > world).
 >
 > On the same example (100 nested collections) my_ST_DumpPoints runs in
 > ~2 seconds which is quite alot. I'll try to come up with a C version,
 > but it seems quite more complicated.

 Hm, the test case is the other way : 10 nested geometry collections of
 100 multipolygons each.

 --
 yabo

 ---MY RESPONSE TO Above
 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).

 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.

 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.

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