[postgis-devel] 1, dot, 3 dot 4!

Obe, Regina robe.dnd at cityofboston.gov
Fri Oct 17 06:29:13 PDT 2008


Paul,

Well hmm looks like despite your cowboy ways you managed not to screw up
too badly and the results are impressive for the most part except for
ST_DWithin. 

I checked the ST_DWithin slowness that was bugging me.   I am seeing
something somewhat disturbing about it.  On first impression For small
st_dwithin checks the new install is about 30% faster, but for larger
st_dwithin checks it actually starts getting slower than the 1.3.3 (and
I would have expected it to be not the case with the _ST_DWithin
short-cut).  I'm suspecting that its nothing wrong with the code and my
first impression is wrong, but rather the nature I am using ST_DWithin
which I imagine may not be that unusual is giving that illusion.  I
think since the old ST_DWithin call used ST_Distance(), then if you did
2 calls say

check within 10 feet, then check within 100 feet (since the
ST_Distance() was cached, the larger buffer was faster since it used a
cached ST_Distance()).  Since ST_DWithin is using the new _ST_DWithin -
I'm guessing its not able to take advantage of caching effects of the
old.  Well that's my suspicion anyway.  I'll have to test further.  

I'm almost wondering what would happen if we changed the definition to 
'SELECT $1 && ST_Expand($2,$3) AND $2 && ST_Expand($1,$3) AND
(_ST_DWithin($1, $2, $3) or ST_Distance($1,$2) < $3)'

On another note - I still would really like to wait till we release
3.1.0 and Mark can include that in the Windows build instead of 3.0.1.
It seems a shame to let all that hard-work go to waste.

I'm also a little bit concerned about the kml regress test failure on my
OpenSUSE 11 box (and I haven't done any tests on that one to see if
there are any other anomalies)


(its not a 1 to 1 compare, but like I said before - when comparing
before the results were much closer and the faster windows 2003 box I
had always won)

Test query 10 feet buffer around Roxbury - okay better
SELECT count(p.pid)
FROM landparcels p INNER JOIN neighborhoods n ON ST_DWithin(p.the_geom,
n.the_geom, 10)
WHERE n.name = 'Roxbury'

So my new stat compares
Windows 2003 - "PostgreSQL 8.2.1 on i686-pc-mingw32, compiled by GCC
gcc.exe (GCC) 3.4.2 (mingw-special)",  "POSTGIS="1.3.3"
GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS"
Takes - 25,438 ms 
result = 11770


On my OpenSUSE VM "PostgreSQL 8.2.6 on i686-pc-linux-gnu, compiled by
GCC gcc (GCC) 4.2.1 (SUSE Linux)" "POSTGIS="1.3.4SVN"
GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS" , 

Takes 17,703 ms 
result = 11770

---This is worse - but I suspect it has to be result of ST_Distance
caching I hadn't considered - the _ST_DWithin would look like functions 
(If I do a fresh neighborhood the numbers are closer I think)
Test query - 100 feet buffer around Roxbury 
SELECT count(p.pid)
FROM landparcels p INNER JOIN neighborhoods n ON ST_DWithin(p.the_geom,
n.the_geom, 100)
WHERE n.name = 'Roxbury'

So my new stat compares
Windows 2003 - "PostgreSQL 8.2.1 on i686-pc-mingw32, compiled by GCC
gcc.exe (GCC) 3.4.2 (mingw-special)",  "POSTGIS="1.3.3"
GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS"
10,203 ms
count = 12,142


On my OpenSUSE VM "PostgreSQL 8.2.6 on i686-pc-linux-gnu, compiled by
GCC gcc (GCC) 4.2.1 (SUSE Linux)" "POSTGIS="1.3.4SVN"
GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS" , 

16,969 ms
count = 12,142

----
Intersects is still pretty impressive with the 3.1.0
SELECT count(p.pid)
FROM landparcels p INNER JOIN neighborhoods n ON
ST_Intersects(p.the_geom, n.the_geom)
WHERE n.name = 'Roxbury'

Windows 2003 - "PostgreSQL 8.2.1 on i686-pc-mingw32, compiled by GCC
gcc.exe (GCC) 3.4.2 (mingw-special)",  "POSTGIS="1.3.3"
GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS"
Takes - 8438 ms 
result = 11721


On my OpenSUSE "PostgreSQL 8.2.6 on i686-pc-linux-gnu, compiled by GCC
gcc (GCC) 4.2.1 (SUSE Linux)" "POSTGIS="1.3.4SVN"
GEOS="3.1.0-CAPI-1.5.0" PROJ="Rel. 4.6.0, 21 Dec 2007" USE_STATS" , 

Takes - 1515 ms 
result - 11721

Thanks,
Regina



-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Friday, October 17, 2008 1:27 AM
To: PostGIS Development Discussion
Subject: [postgis-devel] 1, dot, 3 dot 4!

Let's get this release, out the door!

Goooooo team!

---

So, no howls of pain from testers... shall we release?

P.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.



More information about the postgis-devel mailing list