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

[Obe, Regina]

Mark,
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.

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.

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.

What I mean by that in case it wasn't clear -  

Say you have a geomA  and geomB and you want to check if geomA is within 10 units of geomB

In old implementation would look something like && And ST_Distance(geomA,geomB) < 10
In new would look something like && and _ST_DWithin(geomA,geomB, 10)

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.

so && And ST_Distance(geomA,geomB) < 20  (distance does not need to be recalculated)

but with 

&& AND _ST_DWithin(geomA,geomB,20)   (it has to recalc since its different arguments).


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.

Thanks,
Regina







-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Mark Cave-Ayland
Sent: Sat 10/18/2008 3:11 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] 1, dot, 3 dot 4!
 
Paul Ramsey wrote:
> hooray for precision issues, not sure what to say... ignore it? we
> could pass our input to these tests through snap-to-grid to avoid
> these things, I suppose.
> 
> P

I think we should at least find out why this is happening before/if we 
decide to ignore it. Given that Regina mentions this is a new VM, the 
obvious question is does 1.3.3 exhibit the same behaviour on the same VM?


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081018/d3a01cc5/attachment.html>