From 82849df6c637c09fe484ed11e1035c158f128e81 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sun, 16 Apr 2000 04:41:03 +0000
Subject: Add new selectivity estimation functions for pattern-matching
 operators (LIKE and regexp matches).  These are not yet referenced in
 pg_operator, so by default the system will continue to use eqsel/neqsel.
 Also, tweak convert_to_scalar() logic so that common prefixes of strings are
 stripped off, allowing better accuracy when all strings in a table share a
 common prefix.

---
 doc/src/sgml/xoper.sgml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

(limited to 'doc/src/sgml')

diff --git a/doc/src/sgml/xoper.sgml b/doc/src/sgml/xoper.sgml
index a0513a7051d..2c938148fcd 100644
--- a/doc/src/sgml/xoper.sgml
+++ b/doc/src/sgml/xoper.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.9 2000/03/31 03:27:41 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.10 2000/04/16 04:41:01 tgl Exp $
 -->
 
  <Chapter Id="xoper">
@@ -254,9 +254,9 @@ SELECT (a + b) AS c FROM test_complex;
    <para>
     You can frequently get away with using either eqsel or neqsel for
     operators that have very high or very low selectivity, even if they
-    aren't really equality or inequality.  For example, the regular expression
-    matching operators (~, ~*, etc) use eqsel on the assumption that they'll
-    usually only match a small fraction of the entries in a table.
+    aren't really equality or inequality.  For example, the
+    approximate-equality geometric operators use eqsel on the assumption that
+    they'll usually only match a small fraction of the entries in a table.
    </para>
 
    <para>
-- 
cgit v1.2.3