[postgis-devel] [PostGIS] #230: st_expand seems to affect the execution order wich affects st_dwithin

[PostGIS]

#230: st_expand seems to affect the execution order wich affects st_dwithin
----------------------+-----------------------------------------------------
  Reporter:  nicklas  |       Owner:  robe                     
      Type:  defect   |      Status:  assigned                 
  Priority:  medium   |   Milestone:  postgis 1.4.1            
 Component:  postgis  |     Version:  1.4                      
Resolution:           |    Keywords:  st_dwithin st_expand bbox
----------------------+-----------------------------------------------------
Comment (by robe):

 Why would it? Because its written in SQL, the function is transparent (sql
 functions are generally inlined).  See slides -- the link to the index
 call is part of ST_DWithin.  You will also notice that if you look at the
 pgadmin planner -- the ST_Dwithin call is split into 2 -- the index match
 and the _ST_DWithin with an extra superfluous EXPAND that never uses an
 index).

 The extra expand is simply to make the function symettric.  Even though
 the answers to expand are identical -- one is indexable and one is not
 (and only at run-time would you know which one is and which one isn't) so
 the planner will choose to test the indexable one first and never test the
 rest of the function if the index call fails.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/230#comment:8>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS