[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