[postgis-devel] [PostGIS] #137: ST_ShortestLine, ST_LongestLine, ST_max_distance, ST_DFullyWithin

[PostGIS]

#137: ST_ShortestLine, ST_LongestLine, ST_max_distance, ST_DFullyWithin
------------------------------------+---------------------------------------
  Reporter:  post... at jordogskog.no  |       Owner:  robe         
      Type:  enhancement            |      Status:  assigned     
  Priority:  medium                 |   Milestone:  postgis 1.5.0
 Component:  postgis                |     Version:               
Resolution:                         |    Keywords:               
------------------------------------+---------------------------------------
Comment (by nicklas):

 I get the hint :-)
 It seems like a long way for me to get that make check going in windows,
 but I will give it a try later today...

 About your states the result wasn't that impressing. I thought it would be
 a little bit better, but the real gain is when there is holes in the
 polygons that can be sorted away. I also think there is tuning to be done.
 But it is faster :-)

 My results:

 the first query:
 postgresql 8.3 postgis 1.3.6    with no patch   4371ms result
 131103.250239575
 postgresql 8.4 postgis 1.4.0SVN with no patch   3232ms result
 131103.250239575
 postgresql 8.4 postgis 1.4.0SVN with patch      2327ms result
 131103.250239575

 the second query:
 postgresql 8.3 postgis 1.3.6    with no patch   89485ms result
 745222.745755735
 postgresql 8.4 postgis 1.4.0SVN with no patch   63197ms result
 745222.745755735
 postgresql 8.4 postgis 1.4.0SVN with patch      44423ms result
 745222.745755735

 Beside from this I noted something very strange. Consequently the cpu is
 behaving differently in the different upsets. In this laptop there is a
 Intel Core 2 Duo (Conroe). I don't have any tools to analyze this more
 precise, but in the task manager I can see that in the first case with
 postgresql 8.3 and postgis 1.3.6 the load is balanced between the cores.
 Total cpu-usage is about 50 % and it uses about 50 % per core, but in the
 two cases with postgresql 8.4 with postgis 1.4, both with and without the
 patch it takes all the power from one of the cores. Still getting 50 %
 together, but taking it all from one of them.
 Then I thought that this came from something in postgresql of course, but
 running a patched version of the trunk is getting the same behavior as pg
 8.3 postgis 1.3. Now it is agin balancing the cores and using about 50%
 from each.

 I don't know if the graphics of the task manager is trustable but anyway
 it shows a difference between 1.4 and the other two, 1.3. and 1.5trunk.

 can postgis in anyway affect the cpu-behavior??

 /Nicklas

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