<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [postgis-devel] 1, dot, 3 dot 4!</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Mark,<BR>
I'll try to make a copy of my VM and downgrade to 1.3.3 to see if I suffer the same issues there.<BR>
<BR>
I'm more concerned about the not always improved change in ST_DWithin, but I'm fine with releasing even with that since I haven't quite figured out what the pattern is of the query that is effected or if its a difference between caching of 8.2/8.3.<BR>
<BR>
I think the next test I will run is the same queries I have been running in PostGIS 1.3.4, but using the old ST_DWithin implementation that uses ST_distance instead of _ST_Dwithin and compare the results in the same exact db (that way it will be more of an apple to apple comparison and I can test out my theory that it is the caching effects of ST_Distance() that makes the old perform better sometimes). I haven't figured out when function results are cached and when they are not. Its not always dramatic but when they are its fairly dramatic.<BR>
<BR>
What I mean by that in case it wasn't clear - <BR>
<BR>
Say you have a geomA and geomB and you want to check if geomA is within 10 units of geomB<BR>
<BR>
In old implementation would look something like && And ST_Distance(geomA,geomB) < 10<BR>
In new would look something like && and _ST_DWithin(geomA,geomB, 10)<BR>
<BR>
So if I run the query again but ask for is it within 20 units -- see with a cached ST_Distance(geomA,geomB) it can pull from cache.<BR>
<BR>
so && And ST_Distance(geomA,geomB) < 20 (distance does not need to be recalculated)<BR>
<BR>
but with<BR>
<BR>
&& AND _ST_DWithin(geomA,geomB,20) (it has to recalc since its different arguments).<BR>
<BR>
<BR>
In cases where caching doesn't happen the new implementation is about 30% faster and even more the more you expand out. But oddly in the last test I did with OpenSUSE 11 and windows 2003 (both running on an 8.3, I didn't see caching in either - but I also had a ST_Tranform in there which was maybe preventing caching and I was also testing with smaller geometries vs. my Neighborhood/multipoly test.<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Mark Cave-Ayland<BR>
Sent: Sat 10/18/2008 3:11 AM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] 1, dot, 3 dot 4!<BR>
<BR>
Paul Ramsey wrote:<BR>
> hooray for precision issues, not sure what to say... ignore it? we<BR>
> could pass our input to these tests through snap-to-grid to avoid<BR>
> these things, I suppose.<BR>
><BR>
> P<BR>
<BR>
I think we should at least find out why this is happening before/if we<BR>
decide to ignore it. Given that Regina mentions this is a new VM, the<BR>
obvious question is does 1.3.3 exhibit the same behaviour on the same VM?<BR>
<BR>
<BR>
ATB,<BR>
<BR>
Mark.<BR>
<BR>
--<BR>
Mark Cave-Ayland<BR>
Sirius Corporation - The Open Source Experts<BR>
<A HREF="http://www.siriusit.co.uk">http://www.siriusit.co.uk</A><BR>
T: +44 870 608 0063<BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>