database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-27 22:56:53 +03:00
Code

Add more details.

Browse Source
This commit is contained in:
Peter Eisentraut 2001-02-20 22:27:56 +00:00
parent 824648afae
commit 3a65e4fca6
1 changed files with 328 additions and 109 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

437
doc/src/sgml/indices.sgml
View File

@ -1,132 +1,353 @@
<chapter id="indices"> <!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.14 2001/02/20 22:27:56 petere Exp $ -->
<title id="indices-title">Indices and Keys</title>
<chapter id="indices">
<title id="indices-title">Indices</title>
<para>
Indices 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
overhead to the database system as a whole, so they should be used
sensibly.
</para>
<sect1 id="indices-intro">
<title>Introduction</title>
<para> <para>
Indexes are commonly used to enhance database The classical example for the need of an index is if there is a
performance. They should be defined on table columns (or class table similar to this:
attributes) that are used as qualifications in repetitive queries. <programlisting>
Inappropriate use will result in slower performance, since update CREATE TABLE test1 (
and insertion times are increased in the presence of indices. id integer,
content varchar
);
</programlisting>
and the application requires a lot of queries of the form
<programlisting>
SELECT content FROM test1 WHERE id = <replaceable>constant</replaceable>;
</programlisting>
Ordinarily, the system would have to scan the entire
<structname>test1</structname> table row by row to find all
matching entries. If there are a lot of rows in
<structname>test1</structname> and only a few rows (possibly zero
or one) returned by the query, then this is clearly an inefficient
method. If the system were instructed to maintain an index on the
<structfield>id</structfield> column, then it could use a more
efficient method for locating matching rows. For instance, it
might only have to walk a few levels deep into a search tree.
</para> </para>
<para> <para>
Indexes may also be used to enforce uniqueness of a table's primary key. A similar approach is used in most books of non-fiction: Terms and
When an index is declared UNIQUE, multiple table rows with identical concepts that are frequently looked up by readers are collected in
index entries won't be allowed. an alphabetic index at the end of the book. The interested reader
For this purpose, the goal is ensuring data consistency, not improving can scan the index relatively quickly and flip to the appropriate
performance, so the above caution about inappropriate use doesn't apply. page, and would not have to read the entire book to find the
interesting location. As it is the task of the author to
anticipate the items that the readers are most likely to look up,
it is the task of the database programmer to foresee which indexes
would be of advantage.
</para> </para>
<para> <para>
Two forms of indices may be defined: The following command would be used to create the index on the
<structfield>id</structfield> column, as discussed:
<itemizedlist> <programlisting>
<listitem> CREATE INDEX test1_id_index ON test1 (id);
<para> </programlisting>
For a <firstterm>value index</firstterm>, The name <structname>test1_id_index</structname> can be chosen
the key fields for the freely, but you should pick something that enables you to remember
index are specified as column names; multiple columns later what the index was for.
can be specified if the index access method supports
multi-column indexes.
</para>
</listitem>
<listitem>
<para>
For a <firstterm>functional index</firstterm>, an index is defined
on the result of a function applied
to one or more columns of a single table.
This is a single-column index (namely, the function result)
even if the function uses more than one input field.
Functional indices can be used to obtain fast access to data
based on operators that would normally require some
transformation to apply them to the base data.
</para>
</listitem>
</itemizedlist>
</para> </para>
<para> <para>
Postgres provides btree, rtree and hash access methods for To remove an index, use the <command>DROP INDEX</command> command.
indices. The btree access method is an implementation of Indices can be added and removed from tables at any time.
Lehman-Yao high-concurrency btrees. The rtree access method
implements standard rtrees using Guttman's quadratic split algorithm.
The hash access method is an implementation of Litwin's linear
hashing. We mention the algorithms used solely to indicate that all
of these access methods are fully dynamic and do not have to be
optimized periodically (as is the case with, for example, static hash
access methods).
</para> </para>
<para> <para>
The <productname>Postgres</productname> Once the index is created, no further intervention is required: the
query optimizer will consider using a btree index whenever system will use the index when it thinks it would be more efficient
an indexed attribute is involved in a comparison using one of: than a sequential table scan. But you may have to run the
<command>VACUUM ANALYZE</command> command regularly to update
statistics to allow the query planner to make educated decisions.
Also read <xref linkend="performance-tips"> for information about
how to find out whether an index is used and when and why the
planner may choose to <emphasis>not</emphasis> use an index.
</para>
<para>
Indices 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,
an index defined on a column that is part of a join condition can
significantly speed up queries with joins.
</para>
<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
should be removed.
</para>
</sect1>
<sect1 id="indices-types">
<title>Index Types</title>
<para>
<productname>Postgres</productname> provides several index types:
B-tree, R-tree, and Hash. Each index type is more appropriate for
a particular query type because of the algorithm it uses. By
default, the <command>CREATE INDEX</command> command will create a
B-tree index, which fits the most common situations. In
particular, the <productname>Postgres</productname> query optimizer
will consider using a B-tree index whenever an indexed column is
involved in a comparison using one of these operators:
<simplelist type="inline"> <simplelist type="inline">
<member>&lt;</member> <member><literal>&lt;</literal></member>
<member>&lt;=</member> <member><literal>&lt;=</literal></member>
<member>=</member> <member><literal>=</literal></member>
<member>&gt;=</member> <member><literal>&gt;=</literal></member>
<member>&gt;</member> <member><literal>&gt;</literal></member>
</simplelist> </simplelist>
</para> </para>
<para> <para>
The <productname>Postgres</productname> R-tree indices are especially suited for spacial data. To create
query optimizer will consider using an rtree index whenever an R-tree index, use a command of the form
an indexed attribute is involved in a comparison using one of: <synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING RTREE (<replaceable>column</replaceable>);
</synopsis>
The <productname>Postgres</productname> query optimizer will
consider using an R-tree index whenever an indexed column is
involved in a comparison using one of these operators:
<simplelist type="inline"> <simplelist type="inline">
<member>&lt;&lt;</member> <member><literal>&lt;&lt;</literal></member>
<member>&amp;&lt;</member> <member><literal>&amp;&lt;</literal></member>
<member>&amp;&gt;</member> <member><literal>&amp;&gt;</literal></member>
<member>&gt;&gt;</member> <member><literal>&gt;&gt;</literal></member>
<member>@</member> <member><literal>@</literal></member>
<member>~=</member> <member><literal>~=</literal></member>
<member>&amp;&amp;</member> <member><literal>&amp;&amp;</literal></member>
</simplelist> </simplelist>
(Refer to <xref linkend="functions-geometry"> about the meaning of
these operators.)
</para> </para>
<para> <para>
The <productname>Postgres</productname> The query optimizer will consider using a hash index whenever an
query optimizer will consider using a hash index whenever indexed column is involved in a comparison using the
an indexed attribute is involved in a comparison using <literal>=</literal> operator. The following command is used to
the <literal>=</literal> operator. create a hash index:
<synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING HASH (<replaceable>column</replaceable>);
</synopsis>
<note>
<para>
Because of the limited utility of hash indices, 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
B-trees even for <literal>=</literal> comparisons. Moreover,
hash indices require coarser locks; see <xref
linkend="locking-indices">.
</para>
</note>
</para> </para>
<para> <para>
Currently, only the btree access method supports multi-column The B-tree index is an implementation of Lehman-Yao
indexes. Up to 16 keys may be specified by default (this limit high-concurrency B-trees. The R-tree index method implements
can be altered when building Postgres). standard R-trees using Guttman's quadratic split algorithm. The
hash index is an implementation of Litwin's linear hashing. We
mention the algorithms used solely to indicate that all of these
access methods are fully dynamic and do not have to be optimized
periodically (as is the case with, for example, static hash access
methods).
</para>
</sect1>
<sect1 id="indices-multicolumn">
<title>Multi-Column Indices</title>
<para>
An index can be defined on more than one column. For example, if
you have a table of this form:
<programlisting>
CREATE TABLE test2 (
major int,
minor int,
name varchar
);
</programlisting>
(Say, you keep you your <filename class="directory">/dev</filename>
directory in a database...) and you frequently make queries like
<programlisting>
SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> AND minor = <replaceable>constant</replaceable>;
</programlisting>
then it may be appropriate to define an index on the columns
<structfield>major</structfield> and
<structfield>minor</structfield> together, e.g.,
<programlisting>
CREATE INDEX test2_mm_idx ON test2 (major, minor);
</programlisting>
</para> </para>
<para> <para>
An <firstterm>operator class</firstterm> can be specified for each Currently, only the B-tree implementation supports multi-column
column of an index. The operator class identifies the operators to indices. Up to 16 columns may be specified. (This limit can be
be used by the index for that column. For example, a btree index on altered when building <productname>Postgres</productname>; see the
four-byte integers would use the <literal>int4_ops</literal> class; file <filename>config.h</filename>.)
this operator class includes comparison functions for four-byte </para>
integers. In practice the default operator class for the field's
datatype is usually sufficient. The main point of having operator classes <para>
is that for some datatypes, there could be more than one meaningful The query optimizer can use a multi-column index for queries that
ordering. For example, we might want to sort a complex-number datatype involve the first <parameter>n</parameter> consecutive columns in
either by absolute value or by real part. We could do this by defining the index (when used with appropriate operators), up to the total
two operator classes for the datatype and then selecting the proper number of columns specified in the index definition. For example,
class when making an index. There are also some operator classes with an index on <literal>(a, b, c)</literal> can be used in queries
special purposes: involving all of <literal>a</literal>, <literal>b</literal>, and
<literal>c</literal>, or in queries involving both
<literal>a</literal> and <literal>b</literal>, or in queries
involving only <literal>a</literal>, but not in other combinations.
(In a query involving <literal>a</literal> and <literal>c</literal>
the optimizer might choose to use the index for
<literal>a</literal> only and treat <literal>c</literal> like an
ordinary unindexed column.)
</para>
<para>
Multi-column indexes can only be used if the clauses involving the
indexed columns are joined with <literal>AND</literal>. For instance,
<programlisting>
SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR minor = <replaceable>constant</replaceable>;
</programlisting>
cannot make use of the index <structname>test2_mm_idx</structname>
defined above to look up both columns. (It can be used to look up
only the <structfield>major</structfield> column, however.)
</para>
<para>
Multi-column indices 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.
</para>
</sect1>
<sect1 id="indices-unique">
<title>Unique Indices</title>
<para>
Indexes may also be used to enforce uniqueness of a column's value,
or the uniqueness of the combined values of more than one column.
<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.
</para>
<para>
When an index is declared unique, multiple table rows with equal
indexed values will not be allowed. NULL values are not considered
equal.
</para>
<para>
<productname>PostgreSQL</productname> automatically creates unique
indices when a table is declared with a unique constraint or a
primary key, on the columns that make up the primary key or unique
columns (a multi-column index, if appropriate), to enforce that
constraint. A unique index can be added to a table at any later
time, to add a unique constraint. (But a primary key cannot be
added after table creation.)
</para>
</sect1>
<sect1 id="indices-functional">
<title>Functional Indices</title>
<para>
For a <firstterm>functional index</firstterm>, an index is defined
on the result of a function applied to one or more columns of a
single table. Functional indices can be used to obtain fast access
to data based on the result of function calls.
</para>
<para>
For example, a common way to do case-insensitive comparisons is to
use the <function>lower</function>:
<programlisting>
SELECT * FROM test1 WHERE lower(col1) = 'value';
</programlisting>
In order for that query to be able to use an index, it has to be
defined on the result of the <literal>lower(column)</literal>
operation:
<programlisting>
CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
</programlisting>
</para>
<para>
The function in the index definition can take more than one
argument, but they must be table columns, not constants.
Functional indices are always single-column (namely, the function
result) even if the function uses more than one input field; there
cannot be multi-column indices that contain function calls.
</para>
<tip>
<para>
The restrictions mentioned in the previous paragraph can easily be
worked around by defining custom functions to use in the index
definition that call the desired function(s) internally.
</para>
</tip>
</sect1>
<sect1 id="indices-opclass">
<title>Operator Classes</title>
<para>
An index definition may specify an <firstterm>operator
class</firstterm> for each column of an index.
<synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <replaceable>opclass</replaceable> <optional>, ...</optional>);
</synopsis>
The operator class identifies the operators to be used by the index
for that column. For example, a B-tree index on four-byte integers
would use the <literal>int4_ops</literal> class; this operator
class includes comparison functions for four-byte integers. In
practice the default operator class for the column's data type is
usually sufficient. The main point of having operator classes is
that for some data types, there could be more than one meaningful
ordering. For example, we might want to sort a complex-number data
type either by absolute value or by real part. We could do this by
defining two operator classes for the data type and then selecting
the proper class when making an index. There are also some
operator classes with special purposes:
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
The operator classes <literal>box_ops</literal> and The operator classes <literal>box_ops</literal> and
<literal>bigbox_ops</literal> both support rtree indices on the <literal>bigbox_ops</literal> both support R-tree indices on the
<literal>box</literal> datatype. <literal>box</literal> data type. The difference between them is
The difference between them is that <literal>bigbox_ops</literal> that <literal>bigbox_ops</literal> scales box coordinates down,
scales box coordinates down, to avoid floating point exceptions from to avoid floating point exceptions from doing multiplication,
doing multiplication, addition, and subtraction on very large addition, and subtraction on very large floating point
floating-point coordinates. If the field on which your rectangles lie coordinates. If the field on which your rectangles lie is about
is about 20,000 units square or larger, you should use 20 000 units square or larger, you should use
<literal>bigbox_ops</literal>. <literal>bigbox_ops</literal>.
</para> </para>
</listitem> </listitem>
@ -135,8 +356,7 @@
<para> <para>
The following query shows all defined operator classes: The following query shows all defined operator classes:
<programlisting>
<programlisting>
SELECT am.amname AS acc_name, SELECT am.amname AS acc_name,
opc.opcname AS ops_name, opc.opcname AS ops_name,
opr.oprname AS ops_comp opr.oprname AS ops_comp
@ -145,13 +365,11 @@ SELECT am.amname AS acc_name,
WHERE amop.amopid = am.oid AND WHERE amop.amopid = am.oid AND
amop.amopclaid = opc.oid AND amop.amopclaid = opc.oid AND
amop.amopopr = opr.oid amop.amopopr = opr.oid
ORDER BY acc_name, ops_name, ops_comp ORDER BY acc_name, ops_name, ops_comp;
</programlisting> </programlisting>
</para> </para>
</sect1>
<para>
Use <command>DROP INDEX</command> to remove an index.
</para>
<sect1 id="keys"> <sect1 id="keys">
<title id="keys-title">Keys</title> <title id="keys-title">Keys</title>
@ -169,7 +387,7 @@ SELECT am.amname AS acc_name,
</para> </para>
<para> <para>
<programlisting> <literallayout>
Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
What's the difference between: What's the difference between:
@ -180,7 +398,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
- Is this an alias? - Is this an alias?
- If PRIMARY KEY is already unique, then why - If PRIMARY KEY is already unique, then why
is there another kind of key named UNIQUE? is there another kind of key named UNIQUE?
</programlisting> </literallayout>
</para> </para>
<para> <para>
@ -199,7 +417,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
However, my application requires that each collection will also have a However, my application requires that each collection will also have a
unique name. Why? So that a human being who wants to modify a collection unique name. Why? So that a human being who wants to modify a collection
will be able to identify it. It's much harder to know, if you have two will be able to identify it. It's much harder to know, if you have two
collections named "Life Science", the the one tagged 24433 is the one you collections named <quote>Life Science</quote>, the the one tagged 24433 is the one you
need, and the one tagged 29882 is not. need, and the one tagged 29882 is not.
</para> </para>
@ -213,7 +431,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
<para> <para>
Moreover, despite being unique, the collection name does not actually Moreover, despite being unique, the collection name does not actually
define the collection! For example, if somebody decided to change the name define the collection! For example, if somebody decided to change the name
of the collection from "Life Science" to "Biology", it will still be the of the collection from <quote>Life Science</quote> to <quote>Biology</quote>, it will still be the
same collection, only with a different name. As long as the name is unique, same collection, only with a different name. As long as the name is unique,
that's OK. that's OK.
</para> </para>
@ -256,7 +474,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Are updateable, so long as they are kept unique. Are updatable, so long as they are kept unique.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -284,16 +502,16 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
<para> <para>
Thus, you may query a table by any combination of its columns, despite the Thus, you may query a table by any combination of its columns, despite the
fact that you don't have an index on these columns. The indexes are merely fact that you don't have an index on these columns. The indexes are merely
an implementational aid that each <acronym>RDBMS</acronym> offers an implementation aid that each <acronym>RDBMS</acronym> offers
you, in order to cause you, in order to cause
commonly used queries to be done more efficiently. commonly used queries to be done more efficiently.
Some <acronym>RDBMS</acronym> may give you Some <acronym>RDBMS</acronym> may give you
additional measures, such as keeping a key stored in main memory. They will additional measures, such as keeping a key stored in main memory. They will
have a special command, for example have a special command, for example
<programlisting> <synopsis>
CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt; CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</replaceable>
</programlisting> </synopsis>
(this is not an existing command, just an example). (This is not an existing command, just an example.)
</para> </para>
<para> <para>
@ -318,6 +536,7 @@ CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt;
</para> </para>
</sect1> </sect1>
<sect1 id="partial-index"> <sect1 id="partial-index">
<title id="partial-index-title">Partial Indices</title> <title id="partial-index-title">Partial Indices</title>