[postgis-devel] What's the point of this exercise in intersects?

Obe, Regina robe.dnd at cityofboston.gov
Mon Sep 8 16:26:18 PDT 2008


>> It gets better, since the bbox check often recurs in the GEOS code
>> base too. However, it's not exactly a high cost check, and there are
>> cases where there functions will be called sans indexes. Doing the
>> check in postgis potentially saves a trip to GEOS. The GEOS checks
>> have to be there to support pure-GEOS apps.

>> C'est la vie.

>> P.

Paul,

I wish I could be so accepting of lifeas you. Perhaps life would be much easier for me to bear.

The GEOS bbox extra check I whole-heartedly accept as the price of sharing code.  The
PostGIS one though - it seems even if other projects were sharing PostGIS code, these functions
are so tied to PostgreSQL  that they would be taking advantage of the same treats we are and cursory inspecting the code base
couldn't find a situation where this would be called sans indexes except by newbies (maybe I didn't inspect enough).  

So which places do you see where you would ever call this function and not have already done a bounding box check already?

I know for normal loads this is a not a high cost check, but it seems when you get into the millions this
could become costly.  Take for example Pedro's question

http://postgis.refractions.net/pipermail/postgis-users/2008-September/021061.html

I had dismissed this difference in speed between ST_Dwithin and ST_Intersects, ST_Within , as the cost of
crossing the GEOS barrier.  On further inspection - I see there is a short-circuit for dealing with Point in Polys and he had a point in poly case 
so it should never have crossed the geos barrier anyway (unless this short-circuit isn't in the release version hmm have to check that).  So what is the reason for this discrepancy in timing.  I can't imagine a distance check would be anymore efficient.

Perhaps I'm just making a mountain out of a mole hill though.

Thanks,
Regina










-----------------------------------------
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/20080908/25f873ed/attachment.html>


More information about the postgis-devel mailing list