[postgis-users] speed difference between using operators and st_*functions

[Paragon Corporation]

James,

The ST_Intersects and other ST_ functions usually include a && as part of
them.

They are slower because they do more than a bounding box check.

The &&, @ and other operators just consider the bounding box of the geometry
(a caricature if you will) .  So &&  just ensures that the minimum bounding
rectangle  of two geometries intersect. To be sure that they actually
intersect, you have to do a more exhaustive analysis, which is what the
ST_Intersects  does which is why it is slower than just &&

ST_Intersects as I recall works for geometry collections as well.  Some of
the others do not.

Leo
http://www.postgis.us

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of James
Chamberlain
Sent: Wednesday, June 02, 2010 10:14 PM
To: PostGIS Users Discussion
Subject: [postgis-users] speed difference between using operators and
st_*functions

I have a large dataset with many polygons, points, and geometrycollections
and I have been testing different ways to query with very different results.
I am querying for geometries within a bounding box or a radius from a point.
I seem to get the best performance if I create a polygon to represent the
bounding box or circle and then use operators such as && or @. If I instead
use functions like st_intersects or st_contains the same operation takes
much longer. Is that the expected behavior? Another benefit of using the
operators is that they work with geometrycollections where many of the
functions do not. Is there any reason to prefer the functions over operators
for basic intersection and contains queries?

Thanks,

James

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users