From: Paul Ramsey <pramsey@cleverelephant.ca>
Date: Tue, 20 Nov 2012 19:07:50 +0000 (+0000)
Subject: #1828, Poor selectivity estimate on ST_DWithin
X-Git-Tag: 2.1.0beta2~376
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=942c0dc628611846b339a9b336dad9e377024671;p=postgis

#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 0abf699ef..50f30deb3 100644
--- 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 e2b552f43..54b349fd9 100644
--- 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);
 	}
 
 	/*