[postgis-devel] [PostGIS] #1024: Change 3D relationship functions to use &&& instead of &&
PostGIS
trac at osgeo.org
Mon Nov 14 00:28:10 PST 2011
#1024: Change 3D relationship functions to use &&& instead of &&
---------------------+------------------------------------------------------
Reporter: robe | Owner: pramsey
Type: task | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
---------------------+------------------------------------------------------
Comment(by robe):
Hmm good question. I forgot that a 3D index would satisfy both && and
&&&, though that is my assumption. Paul -- correct me if I am mistaken.
So actually the order should be &&& AND &&.
The way PostgreSQL works -- it will first process the one that can take
advantage of an index all else being equal (not sure how it compares index
costs). If both can utilize an index (it can't tell which is more costly),
then it will process in order.
So my thinking is if a user has a 2D index, then && will be checked first
and then &&& would provide additional filtering before the more costly
_ST_3D regardless of if we do &&& and && or && and &&&.
If they have a 3D index, then &&& will be used first only if we put it in
front (assuming that both && and &&& can take advantage of the index),
followed by && which in theory would be a pointless check but shouldn't
add too much overhead. This is just following precedence of operation
when costs are considered even.
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1024#comment:5>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
More information about the postgis-devel
mailing list