Indices are a common way to enhance database performance. An index
Indexes are a common way to enhance database performance. An index
allows the database server to find and retrieve specific rows much
faster than it could do without an index. But indices also add
faster than it could do without an index. But indexes also add
overhead to the database system as a whole, so they should be used
sensibly.
</para>
<sect1 id="indices-intro">
<sect1 id="indexes-intro">
<title>Introduction</title>
<para>
...
...
@@ -73,7 +68,7 @@ CREATE INDEX test1_id_index ON test1 (id);
<para>
To remove an index, use the <command>DROP INDEX</command> command.
Indices can be added and removed from tables at any time.
Indexes can be added and removed from tables at any time.
</para>
<para>
...
...
@@ -88,10 +83,10 @@ CREATE INDEX test1_id_index ON test1 (id);
</para>
<para>
Indices can also benefit <command>UPDATE</command>s and
Indexes can also benefit <command>UPDATE</command>s and
<command>DELETE</command>s with search conditions. Note that a
query or data manipulation commands can only use at most one index
per table. Indices can also be used in table join methods. Thus,
per table. Indexes can also be used in table join methods. Thus,
an index defined on a column that is part of a join condition can
significantly speed up queries with joins.
</para>
...
...
@@ -99,13 +94,13 @@ CREATE INDEX test1_id_index ON test1 (id);
<para>
When an index is created, it has to be kept synchronized with the
table. This adds overhead to data manipulation operations.
Therefore indices that are non-essential or do not get used at all
Therefore indexes that are non-essential or do not get used at all
should be removed.
</para>
</sect1>
<sect1 id="indices-types">
<sect1 id="indexes-types">
<title>Index Types</title>
<para>
...
...
@@ -113,12 +108,12 @@ CREATE INDEX test1_id_index ON test1 (id);
B-tree, R-tree, and Hash. Each index type is more appropriate for
a particular query type because of the algorithm it uses.
<indexterm>
<primary>indices</primary>
<primary>indexes</primary>
<secondary>B-tree</secondary>
</indexterm>
<indexterm>
<primary>B-tree</primary>
<see>indices</see>
<see>indexes</see>
</indexterm>
By
default, the <command>CREATE INDEX</command> command will create a
...
...
@@ -138,14 +133,14 @@ CREATE INDEX test1_id_index ON test1 (id);
<para>
<indexterm>
<primary>indices</primary>
<primary>indexes</primary>
<secondary>R-tree</secondary>
</indexterm>
<indexterm>
<primary>R-tree</primary>
<see>indices</see>
<see>indexes</see>
</indexterm>
R-tree indices are especially suited for spacial data. To create
R-tree indexes are especially suited for spacial 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>);
...
...
@@ -169,12 +164,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
<para>
<indexterm>
<primary>indices</primary>
<primary>indexes</primary>
<secondary>hash</secondary>
</indexterm>
<indexterm>
<primary>hash</primary>
<see>indices</see>
<see>indexes</see>
</indexterm>
The query optimizer will consider using a hash index whenever an
indexed column is involved in a comparison using the
...
...
@@ -185,12 +180,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
</synopsis>
<note>
<para>
Because of the limited utility of hash indices, a B-tree index
Because of the limited utility of hash indexes, a B-tree index
should generally be preferred over a hash index. We do not have
sufficient evidence that hash indices are actually faster than
sufficient evidence that hash indexes are actually faster than
B-trees even for <literal>=</literal> comparisons. Moreover,
hash indices require coarser locks; see <xref
linkend="locking-indices">.
hash indexes require coarser locks; see <xref
linkend="locking-indexes">.
</para>
</note>
</para>
...
...
@@ -208,11 +203,11 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
</sect1>
<sect1 id="indices-multicolumn">
<title>Multi-Column Indices</title>
<sect1 id="indexes-multicolumn">
<title>Multi-Column Indexes</title>
<indexterm zone="indices-multicolumn">
<primary>indices</primary>
<indexterm zone="indexes-multicolumn">
<primary>indexes</primary>
<secondary>multi-column</secondary>
</indexterm>
...
...
@@ -241,7 +236,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
<para>
Currently, only the B-tree implementation supports multi-column
indices. Up to 16 columns may be specified. (This limit can be
indexes. Up to 16 columns may be specified. (This limit can be
altered when building <productname>Postgres</productname>; see the
file <filename>config.h</filename>.)
</para>
...
...
@@ -274,7 +269,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
</para>
<para>
Multi-column indices should be used sparingly. Most of the time,
Multi-column indexes should be used sparingly. Most of the time,
an index on a single column is sufficient and saves space and time.
Indexes with more than three columns are almost certainly
inappropriate.
...
...
@@ -282,11 +277,11 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
</sect1>
<sect1 id="indices-unique">
<title>Unique Indices</title>
<sect1 id="indexes-unique">
<title>Unique Indexes</title>
<indexterm zone="indices-unique">
<primary>indices</primary>
<indexterm zone="indexes-unique">
<primary>indexes</primary>
<secondary>unique</secondary>
</indexterm>
...
...
@@ -296,7 +291,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
<synopsis>
CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>);
</synopsis>
Only B-tree indices can be declared unique.
Only B-tree indexes can be declared unique.
</para>
<para>
...
...
@@ -307,7 +302,7 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
