[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
----------------------+-----------------------------------------------------
Changes (by robe):

  * owner:  pramsey => robe
  * status:  new => assigned

Comment:

 Nicklas,
 I don't have proof of this, but I suspect this problem only happens with
 really large geometries and also if you don't have a limit or your limit
 reaches a certain threshold.

 I'm putting the blame right square on this st_expand(geometry, double
 precision) overloaded function.  I suspect for large geometries -- this is
 passing the huge geometry down the throat of the C layer (when in theory
 it should just be reading the bounding box and expanding that) in (and
 also some how messing up the planners favor of an index).  Well that's
 just a theory. I haven't fiddled with costs and so forth.

 If you look at our slides -- we some how managed to escape this horrible
 fate you have demonstrated, but I did confirm your results happen even on
 1.3)

 See slide 19 all use indexes except middle one which we wouldn't expect to
 -- strange huh.  Only difference is we use a limit and also we simplify in
 later cases to reduce the size of the geometry.

 http://www.bostongis.com/downloads/oscon2009/Oscon2009_PostGISTips.pdf

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