Adding upstream version 14.5.upstream/14.5upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 96 insertions, 0 deletions

diff --git a/src/backend/utils/adt/geo_selfuncs.c b/src/backend/utils/adt/geo_selfuncs.c
new file mode 100644
index 0000000..db94124
--- /dev/null
+++ b/src/backend/utils/adt/geo_selfuncs.c
@@ -0,0 +1,96 @@
+/*-------------------------------------------------------------------------
+ *
+ * geo_selfuncs.c
+ *	  Selectivity routines registered in the operator catalog in the
+ *	  "oprrest" and "oprjoin" attributes.
+ *
+ * Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1994, Regents of the University of California
+ *
+ *
+ * IDENTIFICATION
+ *	  src/backend/utils/adt/geo_selfuncs.c
+ *
+ *	XXX These are totally bogus.  Perhaps someone will make them do
+ *	something reasonable, someday.
+ *
+ *-------------------------------------------------------------------------
+ */
+#include "postgres.h"
+
+#include "utils/builtins.h"
+#include "utils/geo_decls.h"
+
+
+/*
+ *	Selectivity functions for geometric operators.  These are bogus -- unless
+ *	we know the actual key distribution in the index, we can't make a good
+ *	prediction of the selectivity of these operators.
+ *
+ *	Note: the values used here may look unreasonably small.  Perhaps they
+ *	are.  For now, we want to make sure that the optimizer will make use
+ *	of a geometric index if one is available, so the selectivity had better
+ *	be fairly small.
+ *
+ *	In general, GiST needs to search multiple subtrees in order to guarantee
+ *	that all occurrences of the same key have been found.  Because of this,
+ *	the estimated cost for scanning the index ought to be higher than the
+ *	output selectivity would indicate.  gistcostestimate(), over in selfuncs.c,
+ *	ought to be adjusted accordingly --- but until we can generate somewhat
+ *	realistic numbers here, it hardly matters...
+ */
+
+
+/*
+ * Selectivity for operators that depend on area, such as "overlap".
+ */
+
+Datum
+areasel(PG_FUNCTION_ARGS)
+{
+	PG_RETURN_FLOAT8(0.005);
+}
+
+Datum
+areajoinsel(PG_FUNCTION_ARGS)
+{
+	PG_RETURN_FLOAT8(0.005);
+}
+
+/*
+ *	positionsel
+ *
+ * How likely is a box to be strictly left of (right of, above, below)
+ * a given box?
+ */
+
+Datum
+positionsel(PG_FUNCTION_ARGS)
+{
+	PG_RETURN_FLOAT8(0.1);
+}
+
+Datum
+positionjoinsel(PG_FUNCTION_ARGS)
+{
+	PG_RETURN_FLOAT8(0.1);
+}
+
+/*
+ *	contsel -- How likely is a box to contain (be contained by) a given box?
+ *
+ * This is a tighter constraint than "overlap", so produce a smaller
+ * estimate than areasel does.
+ */
+
+Datum
+contsel(PG_FUNCTION_ARGS)
+{
+	PG_RETURN_FLOAT8(0.001);
+}
+
+Datum
+contjoinsel(PG_FUNCTION_ARGS)
+{
+	PG_RETURN_FLOAT8(0.001);
+}