Use the term "radix tree" instead of "suffix tree" for SP-GiST text opclass.

What we have implemented is a radix tree (or a radix trie or a patricia
trie), but the docs and code comments incorrectly called it a "suffix tree".

Alexander Korotkov

Author: hlinnaka

doc/src/sgml/indices.sgml

@@ -267,7 +267,7 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
    SP-GiST indexes, like GiST indexes, offer an infrastructure that supports
    various kinds of searches.  SP-GiST permits implementation of a wide range
    of different non-balanced disk-based data structures, such as quadtrees,
-   k-d trees, and suffix trees (tries).  As an example, the standard distribution of
+   k-d trees, and radix trees (tries).  As an example, the standard distribution of
    <productname>PostgreSQL</productname> includes SP-GiST operator classes
    for two-dimensional points, which support indexed
    queries using these operators:

doc/src/sgml/spgist.sgml

@@ -15,7 +15,7 @@
   <acronym>SP-GiST</acronym> is an abbreviation for space-partitioned
   <acronym>GiST</acronym>.  <acronym>SP-GiST</acronym> supports partitioned
   search trees, which facilitate development of a wide range of different
-  non-balanced data structures, such as quad-trees, k-d trees, and suffix
+  non-balanced data structures, such as quad-trees, k-d trees, and radix
   trees (tries).  The common feature of these structures is that they
   repeatedly divide the search space into partitions that need not be
   of equal size.  Searches that are well matched to the partitioning rule
@@ -81,9 +81,9 @@
   A node contains a downlink that leads to either another, lower-level inner
   tuple, or a short list of leaf tuples that all lie on the same index page.
   Each node has a <firstterm>label</> that describes it; for example,
-  in a suffix tree the node label could be the next character of the string
+  in a radix tree the node label could be the next character of the string
   value.  Optionally, an inner tuple can have a <firstterm>prefix</> value
-  that describes all its members.  In a suffix tree this could be the common
+  that describes all its members.  In a radix tree this could be the common
   prefix of the represented strings.  The prefix value is not necessarily
   really a prefix, but can be any data needed by the operator class;
   for example, in a quad-tree it can store the central point that the four
@@ -636,7 +636,7 @@ typedef struct spgLeafConsistentOut
   <para>
    Individual leaf tuples and inner tuples must fit on a single index page
    (8KB by default).  Therefore, when indexing values of variable-length
-   data types, long values can only be supported by methods such as suffix
+   data types, long values can only be supported by methods such as radix
    trees, in which each level of the tree includes a prefix that is short
    enough to fit on a page, and the final leaf level includes a suffix also
    short enough to fit on a page.  The operator class should set
@@ -740,7 +740,7 @@ typedef struct spgLeafConsistentOut
  <para>
   The <productname>PostgreSQL</productname> source distribution includes
   several examples of index operator classes for
-  <acronym>SP-GiST</acronym>.  The core system currently provides suffix
+  <acronym>SP-GiST</acronym>.  The core system currently provides radix
   trees over text columns and two types of trees over points: quad-tree and
   k-d tree.  Look into <filename>src/backend/access/spgist/</> to see the
   code.

src/backend/access/spgist/README

@@ -2,7 +2,7 @@ src/backend/access/spgist/README
 
 SP-GiST is an abbreviation of space-partitioned GiST.  It provides a
 generalized infrastructure for implementing space-partitioned data
-structures, such as quadtrees, k-d trees, and suffix trees (tries).  When
+structures, such as quadtrees, k-d trees, and radix trees (tries).  When
 implemented in main memory, these structures are usually designed as a set of
 dynamically-allocated nodes linked by pointers.  This is not suitable for
 direct storing on disk, since the chains of pointers can be rather long and
@@ -56,18 +56,18 @@ Inner tuple consists of:
 
   optional prefix value - all successors must be consistent with it.
     Example:
-        suffix tree  - prefix value is a common prefix string
+        radix tree   - prefix value is a common prefix string
         quad tree    - centroid
         k-d tree     - one coordinate
 
   list of nodes, where node is a (label, pointer) pair.
-    Example of a label: a single character for suffix tree
+    Example of a label: a single character for radix tree
 
 Leaf tuple consists of:
 
   a leaf value
     Example:
-        suffix tree - the rest of string (postfix)
+        radix tree - the rest of string (postfix)
         quad and k-d tree - the point itself
 
   ItemPointer to the heap
@@ -122,7 +122,7 @@ space is as good as we can easily make it.
 (2) Current implementation allows to do picksplit and insert a new leaf tuple
 in one operation, if the new list of leaf tuples fits on one page. It's
 always possible for trees with small nodes like quad tree or k-d tree, but
-suffix trees may require another picksplit.
+radix trees may require another picksplit.
 
 (3) Addition of node must keep size of inner tuple small enough to fit on a
 page.  After addition, inner tuple could become too large to be stored on
@@ -132,14 +132,14 @@ another page, we can't change the numbers of other tuples on the page, else
 we'd make downlink pointers to them invalid. To prevent that, SP-GiST leaves
 a "placeholder" tuple, which can be reused later whenever another tuple is
 added to the page. See also Concurrency and Vacuum sections below. Right now
-only suffix trees could add a node to the tuple; quad trees and k-d trees
+only radix trees could add a node to the tuple; quad trees and k-d trees
 make all possible nodes at once in PickSplitFn() call.
 
 (4) Prefix value could only partially match a new value, so the SplitTuple
 action allows breaking the current tree branch into upper and lower sections.
 Another way to say it is that we can split the current inner tuple into
 "prefix" and "postfix" parts, where the prefix part is able to match the
-incoming new value. Consider example of insertion into a suffix tree. We use
+incoming new value. Consider example of insertion into a radix tree. We use
 the following notation, where tuple's id is just for discussion (no such id
 is actually stored):
 

src/backend/access/spgist/spgtextproc.c

@@ -1,7 +1,7 @@
 /*-------------------------------------------------------------------------
  *
  * spgtextproc.c
- *	  implementation of compressed-suffix tree over text
+ *	  implementation of radix tree (compressed trie) over text
  *
  *
  * Portions Copyright (c) 1996-2013, PostgreSQL Global Development Group
@@ -23,7 +23,7 @@
 
 
 /*
- * In the worst case, a inner tuple in a text suffix tree could have as many
+ * In the worst case, a inner tuple in a text radix tree could have as many
  * as 256 nodes (one for each possible byte value).  Each node can take 16
  * bytes on MAXALIGN=8 machines.  The inner tuple must fit on an index page
  * of size BLCKSZ.	Rather than assuming we know the exact amount of overhead

src/include/catalog/pg_proc.h

@@ -4700,15 +4700,15 @@ DATA(insert OID = 4026 (  spg_kd_inner_consistent	PGNSP PGUID 12 1 0 0 0 f f f f
 DESCR("SP-GiST support for k-d tree over point");
 
 DATA(insert OID = 4027 (  spg_text_config	PGNSP PGUID 12 1 0 0 0 f f f f t f i 2 0 2278 "2281 2281" _null_ _null_ _null_ _null_  spg_text_config _null_ _null_ _null_ ));
-DESCR("SP-GiST support for suffix tree over text");
+DESCR("SP-GiST support for radix tree over text");
 DATA(insert OID = 4028 (  spg_text_choose	PGNSP PGUID 12 1 0 0 0 f f f f t f i 2 0 2278 "2281 2281" _null_ _null_ _null_ _null_  spg_text_choose _null_ _null_ _null_ ));
-DESCR("SP-GiST support for suffix tree over text");
+DESCR("SP-GiST support for radix tree over text");
 DATA(insert OID = 4029 (  spg_text_picksplit	PGNSP PGUID 12 1 0 0 0 f f f f t f i 2 0 2278 "2281 2281" _null_ _null_ _null_ _null_  spg_text_picksplit _null_ _null_ _null_ ));
-DESCR("SP-GiST support for suffix tree over text");
+DESCR("SP-GiST support for radix tree over text");
 DATA(insert OID = 4030 (  spg_text_inner_consistent PGNSP PGUID 12 1 0 0 0 f f f f t f i 2 0 2278 "2281 2281" _null_ _null_ _null_ _null_  spg_text_inner_consistent _null_ _null_ _null_ ));
-DESCR("SP-GiST support for suffix tree over text");
+DESCR("SP-GiST support for radix tree over text");
 DATA(insert OID = 4031 (  spg_text_leaf_consistent	PGNSP PGUID 12 1 0 0 0 f f f f t f i 2 0 16 "2281 2281" _null_ _null_ _null_ _null_  spg_text_leaf_consistent _null_ _null_ _null_ ));
-DESCR("SP-GiST support for suffix tree over text");
+DESCR("SP-GiST support for radix tree over text");
 
 DATA(insert OID = 3469 (  spg_range_quad_config	PGNSP PGUID 12 1 0 0 0 f f f f t f i 2 0 2278 "2281 2281" _null_ _null_ _null_ _null_  spg_range_quad_config _null_ _null_ _null_ ));
 DESCR("SP-GiST support for quad tree over range");