R-tree is dead ... long live GiST.

Author: tglsfdc

contrib/cube/cube.c

@@ -10,7 +10,7 @@
 #include <math.h>
 
 #include "access/gist.h"
-#include "access/rtree.h"
+#include "access/skey.h"
 #include "lib/stringinfo.h"
 #include "utils/builtins.h"
 

contrib/intarray/_int.h

@@ -4,7 +4,7 @@
 
 #include "access/gist.h"
 #include "access/itup.h"
-#include "access/rtree.h"
+#include "access/skey.h"
 #include "catalog/pg_type.h"
 #include "utils/array.h"
 #include "utils/builtins.h"

contrib/ltree/_ltree_gist.c

@@ -5,8 +5,7 @@
 
 #include "ltree.h"
 #include "access/gist.h"
-#include "access/rtree.h"
-#include "access/nbtree.h"
+#include "access/skey.h"
 #include "utils/array.h"
 
 #include "crc32.h"

contrib/ltree/ltree_gist.c

@@ -5,8 +5,8 @@
 
 #include "ltree.h"
 #include "access/gist.h"
-#include "access/rtree.h"
 #include "access/nbtree.h"
+#include "access/skey.h"
 #include "utils/array.h"
 #include "crc32.h"
 

contrib/pg_trgm/trgm_gist.c

@@ -2,13 +2,10 @@
 
 #include "access/gist.h"
 #include "access/itup.h"
-#include "access/rtree.h"
-#include "utils/elog.h"
-#include "utils/palloc.h"
+#include "access/tuptoaster.h"
+#include "storage/bufpage.h"
 #include "utils/array.h"
 #include "utils/builtins.h"
-#include "storage/bufpage.h"
-#include "access/tuptoaster.h"
 
 PG_FUNCTION_INFO_V1(gtrgm_in);
 Datum		gtrgm_in(PG_FUNCTION_ARGS);

contrib/seg/seg.c

@@ -9,7 +9,7 @@
 #include <float.h>
 
 #include "access/gist.h"
-#include "access/rtree.h"
+#include "access/skey.h"
 #include "utils/builtins.h"
 
 #include "segdata.h"
@@ -53,7 +53,7 @@ bool	   *gseg_same(SEG * b1, SEG * b2, bool *result);
 
 
 /*
-** R-tree suport functions
+** R-tree support functions
 */
 bool		seg_same(SEG * a, SEG * b);
 bool		seg_contains_int(SEG * a, int *b);

contrib/tsearch2/gistidx.c

@@ -4,11 +4,10 @@
 
 #include "access/gist.h"
 #include "access/itup.h"
-#include "access/rtree.h"
+#include "access/tuptoaster.h"
+#include "storage/bufpage.h"
 #include "utils/array.h"
 #include "utils/builtins.h"
-#include "storage/bufpage.h"
-#include "access/tuptoaster.h"
 
 #include "tsvector.h"
 #include "query.h"

contrib/tsearch2/query.c

@@ -15,10 +15,9 @@
 
 #include "access/gist.h"
 #include "access/itup.h"
-#include "access/rtree.h"
+#include "storage/bufpage.h"
 #include "utils/array.h"
 #include "utils/builtins.h"
-#include "storage/bufpage.h"
 
 #include "ts_cfg.h"
 #include "tsvector.h"

contrib/tsearch2/rewrite.c

@@ -9,7 +9,6 @@
 
 #include "access/gist.h"
 #include "access/itup.h"
-#include "access/rtree.h"
 #include "storage/bufpage.h"
 #include "utils/array.h"
 #include "utils/builtins.h"

doc/src/sgml/backup.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.75 2005/11/04 23:13:59 petere Exp $
+$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.76 2005/11/07 17:36:44 tgl Exp $
 -->
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -1129,8 +1129,8 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
   <itemizedlist>
    <listitem>
     <para>
-     Operations on hash and R-tree indexes are
-     not presently WAL-logged, so replay will not update these index types.
+     Operations on hash indexes are
+     not presently WAL-logged, so replay will not update these indexes.
      The recommended workaround is to manually <command>REINDEX</> each
      such index after completing a recovery operation.
     </para>

doc/src/sgml/geqo.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/geqo.sgml,v 1.33 2005/10/25 13:38:09 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/geqo.sgml,v 1.34 2005/11/07 17:36:44 tgl Exp $
 Genetic Optimizer
 -->
 
@@ -51,8 +51,8 @@ Genetic Optimizer
     caused by the support of a variety of <firstterm>join
     methods</firstterm> (e.g., nested loop, hash join, merge join in
     <productname>PostgreSQL</productname>) to process individual joins
-    and a diversity of <firstterm>indexes</firstterm> (e.g., R-tree,
-    B-tree, hash in <productname>PostgreSQL</productname>) as access
+    and a diversity of <firstterm>indexes</firstterm> (e.g.,
+    B-tree, hash, GiST in <productname>PostgreSQL</productname>) as access
     paths for relations.
    </para>
 

doc/src/sgml/gist.sgml

@@ -1,25 +1,22 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.24 2005/11/04 23:14:00 petere Exp $
+$PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.25 2005/11/07 17:36:44 tgl Exp $
 -->
 
 <chapter id="GiST">
 <title>GiST Indexes</title>
 
-<sect1 id="gist-intro">
- <title>Introduction</title>
-
- <para>
    <indexterm>
     <primary>index</primary>
     <secondary>GiST</secondary>
    </indexterm>
-   <indexterm>
-    <primary>GiST</primary>
-    <see>index</see>
-   </indexterm>
+
+<sect1 id="gist-intro">
+ <title>Introduction</title>
+
+ <para>
    <acronym>GiST</acronym> stands for Generalized Search Tree.  It is a
    balanced, tree-structured access method, that acts as a base template in
-   which to implement arbitrary indexing schemes. B+-trees, R-trees and many
+   which to implement arbitrary indexing schemes. B-trees, R-trees and many
    other indexing schemes can be implemented in <acronym>GiST</acronym>.
  </para>
 
@@ -60,17 +57,17 @@ $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.24 2005/11/04 23:14:00 petere Exp
  <para>
    This extensibility should not be confused with the extensibility of the
    other standard search trees in terms of the data they can handle.  For
-   example, <productname>PostgreSQL</productname> supports extensible B+-trees
-   and R-trees. That means that you can use
-   <productname>PostgreSQL</productname> to build a B+-tree or R-tree over any
-   data type you want. But B+-trees only support range predicates
+   example, <productname>PostgreSQL</productname> supports extensible B-trees
+   and hash indexes. That means that you can use
+   <productname>PostgreSQL</productname> to build a B-tree or hash over any
+   data type you want. But B-trees only support range predicates
    (<literal>&lt;</literal>, <literal>=</literal>, <literal>&gt;</literal>),
-   and R-trees only support n-D range queries (contains, contained, equals).
+   and hash indexes only support equality queries.
  </para>
 
  <para>
    So if you index, say, an image collection with a
-   <productname>PostgreSQL</productname> B+-tree, you can only issue queries
+   <productname>PostgreSQL</productname> B-tree, you can only issue queries
    such as <quote>is imagex equal to imagey</quote>, <quote>is imagex less
    than imagey</quote> and <quote>is imagex greater than imagey</quote>?
    Depending on how you define <quote>equals</quote>, <quote>less than</quote>
@@ -84,7 +81,7 @@ $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.24 2005/11/04 23:14:00 petere Exp
    All it takes to get a <acronym>GiST</acronym> access method up and running
    is to implement seven user-defined methods, which define the behavior of
    keys in the tree. Of course these methods have to be pretty fancy to
-   support fancy queries, but for all the standard queries (B+-trees,
+   support fancy queries, but for all the standard queries (B-trees,
    R-trees, etc.) they're relatively straightforward. In short,
    <acronym>GiST</acronym> combines extensibility along with generality, code
    reuse, and a clean interface.

doc/src/sgml/indices.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.54 2005/11/04 23:14:00 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.55 2005/11/07 17:36:44 tgl Exp $ -->
 
 <chapter id="indexes">
  <title id="indexes-title">Indexes</title>
@@ -104,7 +104,7 @@ CREATE INDEX test1_id_index ON test1 (id);
 
   <para>
    <productname>PostgreSQL</productname> provides several index types:
-   B-tree, R-tree, Hash, and GiST.  Each index type uses a different
+   B-tree, Hash, and GiST.  Each index type uses a different
    algorithm that is best suited to different types of queries.
    By default, the <command>CREATE INDEX</command> command will create a
    B-tree index, which fits the most common situations.
@@ -152,43 +152,6 @@ CREATE INDEX test1_id_index ON test1 (id);
    See <xref linkend="indexes-opclass"> below.
   </para>
 
-  <para>
-   <indexterm>
-    <primary>index</primary>
-    <secondary>R-tree</secondary>
-   </indexterm>
-   <indexterm>
-    <primary>R-tree</primary>
-    <see>index</see>
-   </indexterm>
-   R-tree indexes are suited for queries on two-dimensional spatial data.
-   To create an R-tree index, use a command of the form
-<synopsis>
-CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING rtree (<replaceable>column</replaceable>);
-</synopsis>
-   The <productname>PostgreSQL</productname> query planner will
-   consider using an R-tree index whenever an indexed column is
-   involved in a comparison using one of these operators:
-
-   <simplelist>
-    <member><literal>&lt;&lt;</literal></member>
-    <member><literal>&amp;&lt;</literal></member>
-    <member><literal>&amp;&gt;</literal></member>
-    <member><literal>&gt;&gt;</literal></member>
-    <member><literal>&lt;&lt;|</literal></member>
-    <member><literal>&amp;&lt;|</literal></member>
-    <member><literal>|&amp;&gt;</literal></member>
-    <member><literal>|&gt;&gt;</literal></member>
-    <member><literal>~</literal></member>
-    <member><literal>@</literal></member>
-    <member><literal>~=</literal></member>
-    <member><literal>&amp;&amp;</literal></member>
-   </simplelist>
-
-   (See <xref linkend="functions-geometry"> for the meaning of
-   these operators.)
-  </para>
-
   <para>
    <indexterm>
     <primary>index</primary>
@@ -208,18 +171,6 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
 </synopsis>
   </para>
 
-  <para>
-   GiST indexes are not a single kind of index, but rather an infrastructure
-   within which many different indexing strategies can be implemented.
-   Accordingly, the particular operators with which a GiST index can be
-   used vary depending on the indexing strategy (the <firstterm>operator
-   class</>).  The standard distribution of
-   <productname>PostgreSQL</productname> includes GiST operator classes
-   equivalent to the R-tree operator classes, and many other GiST operator
-   classes are available in the <literal>contrib</> collection or as separate
-   projects.  For more information see <xref linkend="GiST">.
-  </para>
-
   <note>
    <para>
     Testing has shown <productname>PostgreSQL</productname>'s hash
@@ -230,21 +181,47 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
     after a database crash.
     For these reasons, hash index use is presently discouraged.
    </para>
+  </note>  
 
-   <para>
-    Similarly, R-tree indexes do not seem to have any performance
-    advantages compared to the equivalent operations of GiST indexes.
-    Like hash indexes, they are not WAL-logged and may need
-    reindexing after a database crash.
-   </para>
+  <para>
+   <indexterm>
+    <primary>index</primary>
+    <secondary>GiST</secondary>
+   </indexterm>
+   <indexterm>
+    <primary>GiST</primary>
+    <see>index</see>
+   </indexterm>
+   GiST indexes are not a single kind of index, but rather an infrastructure
+   within which many different indexing strategies can be implemented.
+   Accordingly, the particular operators with which a GiST index can be
+   used vary depending on the indexing strategy (the <firstterm>operator
+   class</>).  As an example, the standard distribution of
+   <productname>PostgreSQL</productname> includes GiST operator classes
+   for several two-dimensional geometric data types, which support indexed
+   queries using these operators:
 
-   <para>
-    While the problems with hash indexes may be fixed eventually,
-    it is likely that the R-tree index type will be retired in a future
-    release.  Users are encouraged to migrate applications that use R-tree
-    indexes to GiST indexes.
-   </para>
-  </note>  
+   <simplelist>
+    <member><literal>&lt;&lt;</literal></member>
+    <member><literal>&amp;&lt;</literal></member>
+    <member><literal>&amp;&gt;</literal></member>
+    <member><literal>&gt;&gt;</literal></member>
+    <member><literal>&lt;&lt;|</literal></member>
+    <member><literal>&amp;&lt;|</literal></member>
+    <member><literal>|&amp;&gt;</literal></member>
+    <member><literal>|&gt;&gt;</literal></member>
+    <member><literal>~</literal></member>
+    <member><literal>@</literal></member>
+    <member><literal>~=</literal></member>
+    <member><literal>&amp;&amp;</literal></member>
+   </simplelist>
+
+   (See <xref linkend="functions-geometry"> for the meaning of
+   these operators.)
+   Many other GiST operator
+   classes are available in the <literal>contrib</> collection or as separate
+   projects.  For more information see <xref linkend="GiST">.
+  </para>
  </sect1>
 
 

doc/src/sgml/mvcc.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.52 2005/10/21 01:41:28 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.53 2005/11/07 17:36:44 tgl Exp $
 -->
 
  <chapter id="mvcc">
@@ -991,18 +991,6 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
        </para>
       </listitem>
      </varlistentry>
-
-     <varlistentry>
-      <term>
-       R-tree indexes
-      </term>
-      <listitem>
-       <para>
-        Share/exclusive index-level locks are used for read/write access.
-        Locks are released after the entire command is done.
-       </para>
-      </listitem>
-     </varlistentry>
     </variablelist>
    </para>
 
@@ -1012,8 +1000,7 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
     indexes, they are the recommended index type for concurrent
     applications that need to index scalar data. When dealing with
     non-scalar data, B-trees are not useful, and GiST indexes should
-    be used instead.  R-tree indexes are deprecated and are likely
-    to disappear entirely in a future release.
+    be used instead.
    </para>
   </sect1>
  </chapter>