Change "indices" to "indexes", per OED.

Author: petere

doc/src/sgml/arch-dev.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.13 2000/12/26 00:10:37 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.14 2001/05/17 21:50:15 petere Exp $
 -->
 
  <chapter id="overview">
@@ -603,7 +603,7 @@ current context are performed.
 
     <para>
      The planner/optimizer decides which plans should be generated
-     based upon the types of indices defined on the relations appearing in
+     based upon the types of indexes defined on the relations appearing in
      a query. There is always the possibility of performing a
      sequential scan on a relation, so a plan using only
      sequential scans is always created. Assume an index is defined on a
@@ -612,7 +612,7 @@ current context are performed.
      <literal>relation.attribute OPR constant</literal>. If
      <literal>relation.attribute</literal> happens to match the key of the B-tree
      index and <literal>OPR</literal> is anything but '&lt;&gt;' another plan is created using
-     the B-tree index to scan the relation. If there are further indices
+     the B-tree index to scan the relation. If there are further indexes
      present and the restrictions in the query happen to match a key of an
      index further plans will be considered.
     </para>
@@ -889,7 +889,7 @@ The {\tt AGG} node is followed by a {\tt GRP} node. The implementation
 of the {\it grouping} logic needs a sorted table for its operation so
 the {\tt GRP} node is followed by a {\tt SORT} node. The {\tt SORT}
 operation gets its tuples from a kind of {\tt Scan} node (if no
-indices are present this will be a simple {\tt SeqScan} node). Any
+indexes are present this will be a simple {\tt SeqScan} node). Any
 qualifications present are attached to the {\tt Scan} node. Figure
 \ref{plan_having} shows the {\it plan} created for the query given in
 example \ref{having}.

doc/src/sgml/backup.sgml

@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.8 2001/05/17 21:12:48 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.9 2001/05/17 21:50:15 petere Exp $ -->
 <chapter id="backup">
  <title>Backup and Restore</title>
 
@@ -355,7 +355,7 @@ tar -cf backup.tar /usr/local/pgsql/data
    Also note that the file system backup will not necessarily be
    smaller than an SQL dump. On the contrary, it will most likely be
    larger. (<application>pg_dump</application> does not need to dump
-   the contents of indices for example, just the commands to recreate
+   the contents of indexes for example, just the commands to recreate
    them.)
   </para>
 

doc/src/sgml/extend.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.10 2001/05/17 21:50:15 petere Exp $
 -->
 
  <chapter id="extend">
@@ -96,7 +96,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
     file that stores all rows of a table)  but  the
     user can "look inside" at the attributes of these types
     from the query language and optimize their retrieval by
-    (for example) defining indices on the attributes.
+    (for example) defining indexes on the attributes.
     <productname>Postgres</productname>  base  types are further
     divided into built-in
     types and user-defined  types.   Built-in  types  (like
@@ -149,7 +149,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
        </row>
        <row>
 	<entry>pg_index</entry>
-	<entry> secondary indices</entry>
+	<entry> secondary indexes</entry>
        </row>
        <row>
 	<entry>pg_proc</entry>
@@ -256,7 +256,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
        pg_am,   pg_amop,   pg_amproc,  pg_operator  and
        pg_opclass are particularly hard  to  understand
        and  will  be described in depth (in the section
-       on interfacing types and operators  to  indices)
+       on interfacing types and operators  to  indexes)
        after we have discussed basic extensions.
       </para>
      </listitem>

doc/src/sgml/geqo.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.16 2001/04/20 15:52:33 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.17 2001/05/17 21:50:15 petere Exp $
 Genetic Optimizer
 -->
 
@@ -51,8 +51,8 @@ Genetic Optimizer
     <firstterm>join methods</firstterm>
     (e.g., nested loop, hash join, merge join in <productname>Postgres</productname>) to
     process individual <command>join</command>s and a diversity of
-    <firstterm>indices</firstterm> (e.g., r-tree,
-    b-tree, hash in <productname>Postgres</productname>) as access paths for relations.
+    <firstterm>indexes</firstterm> (e.g., R-tree,
+    B-tree, hash in <productname>Postgres</productname>) as access paths for relations.
    </para>
 
    <para>

doc/src/sgml/gist.sgml

@@ -8,7 +8,7 @@
 </AuthorGroup>
 <Date>Transcribed 1998-02-19</Date>
 </DocInfo>
-<Title>GiST Indices</Title>
+<Title>GiST Indexes</Title>
 
 <Para>
 The information about GIST is at