[postgis-devel] [PostGIS] #137: ST_ShortestLine, ST_LongestLine, ST_max_distance, ST_DFullyWithin
PostGIS
trac at osgeo.org
Tue Jul 21 02:11:45 PDT 2009
#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
More information about the postgis-devel
mailing list