#1828, Poor selectivity estimate on ST_DWithin

git-svn-id: http://svn.osgeo.org/postgis/trunk@10719 b70326c6-7e19-0410-871a-916f4a2858ee

diff --git a/postgis/geography_estimate.c b/postgis/geography_estimate.c
index 0abf699ef589f1b54cf4db1a95a3acb401175617..50f30deb30d3b29a27154011f6f75b80d6f7c19c 100644 (file)
--- a/postgis/geography_estimate.c
+++ b/postgis/geography_estimate.c
@@ -491,22 +491,25 @@ Datum geography_gist_selectivity(PG_FUNCTION_ARGS)
        }
 
        /*
-        * We are working on two constants..
-        * TODO: check if expression is true,
-        *       returned set would be either
-        *       the whole or none.
-        */
+       * We don't have a nice <const> && <var> or <var> && <const> 
+       * situation here. <const> && <const> would probably get evaluated
+       * away by PgSQL earlier on. <func> && <const> is harder, and the
+       * case we get often is <const> && ST_Expand(<var>), which does 
+       * actually have a subtly different selectivity than a bae
+       * <const> && <var> call. It's calculatable though, by expanding
+       * every cell in the histgram appropriately.
+       * 
+       * Discussion: http://trac.osgeo.org/postgis/ticket/1828
+       *
+       * To do? Do variable selectivity based on the <func> node.
+       */
        if ( ! IsA(self, Var) )
        {
-               POSTGIS_DEBUG(3, " no variable argument ? - returning default selectivity");
-
-               PG_RETURN_FLOAT8(DEFAULT_GEOGRAPHY_SEL);
+               POSTGIS_DEBUG(3, " no bare variable argument ? - returning a moderate selectivity");
+//             PG_RETURN_FLOAT8(DEFAULT_GEOMETRY_SEL);
+               PG_RETURN_FLOAT8(0.33333);
        }
-
-       /*
-        * Convert the constant to a GBOX
-        */
-
+       
        /* Convert coordinates to 3D geodesic */
        FLAGS_SET_GEODETIC(search_box.flags, 1);
        if ( ! gserialized_datum_get_gbox_p(((Const*)other)->constvalue, &search_box) )

diff --git a/postgis/geometry_estimate.c b/postgis/geometry_estimate.c
index e2b552f436400fac0bd6398aa99481ea5d349836..54b349fd912ab0c369fa277c87466e8f46f82adc 100644 (file)
--- a/postgis/geometry_estimate.c
+++ b/postgis/geometry_estimate.c
@@ -674,22 +674,30 @@ Datum geometry_gist_sel_2d(PG_FUNCTION_ARGS)
 
        if ( ! IsA(other, Const) )
        {
-               POSTGIS_DEBUG(3, " no constant arguments - returning default selectivity");
+               POSTGIS_DEBUG(3, " no constant arguments - returning a default selectivity");
 
                PG_RETURN_FLOAT8(DEFAULT_GEOMETRY_SEL);
+//             PG_RETURN_FLOAT8(0.33333);
        }
 
        /*
-        * We are working on two constants..
-        * TODO: check if expression is true,
-        *       returned set would be either
-        *       the whole or none.
-        */
+       * We don't have a nice <const> && <var> or <var> && <const> 
+       * situation here. <const> && <const> would probably get evaluated
+       * away by PgSQL earlier on. <func> && <const> is harder, and the
+       * case we get often is <const> && ST_Expand(<var>), which does 
+       * actually have a subtly different selectivity than a bae
+       * <const> && <var> call. It's calculatable though, by expanding
+       * every cell in the histgram appropriately.
+       * 
+       * Discussion: http://trac.osgeo.org/postgis/ticket/1828
+       *
+       * To do? Do variable selectivity based on the <func> node.
+       */
        if ( ! IsA(self, Var) )
        {
-               POSTGIS_DEBUG(3, " no variable argument ? - returning default selectivity");
-
-               PG_RETURN_FLOAT8(DEFAULT_GEOMETRY_SEL);
+               POSTGIS_DEBUG(3, " no bare variable argument ? - returning a moderate selectivity");
+//             PG_RETURN_FLOAT8(DEFAULT_GEOMETRY_SEL);
+               PG_RETURN_FLOAT8(0.33333);
        }
 
        /*