mirror of
https://github.com/postgres/postgres.git
synced 2025-07-28 23:42:10 +03:00
Multi-column GIN indexes. Teodor Sigaev
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.73 2008/05/27 00:13:08 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.74 2008/07/11 21:06:28 tgl Exp $ -->
|
||||
|
||||
<chapter id="indexes">
|
||||
<title id="indexes-title">Indexes</title>
|
||||
@ -198,7 +198,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
after a database crash.
|
||||
For these reasons, hash index use is presently discouraged.
|
||||
</para>
|
||||
</note>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
@ -250,9 +250,9 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
</indexterm>
|
||||
GIN indexes are inverted indexes which can handle values that contain more
|
||||
than one key, arrays for example. Like GiST, GIN can support
|
||||
many different user-defined indexing strategies and the particular
|
||||
operators with which a GIN index can be used vary depending on the
|
||||
indexing strategy.
|
||||
many different user-defined indexing strategies and the particular
|
||||
operators with which a GIN index can be used vary depending on the
|
||||
indexing strategy.
|
||||
As an example, the standard distribution of
|
||||
<productname>PostgreSQL</productname> includes GIN operator classes
|
||||
for one-dimensional arrays, which support indexed
|
||||
@ -306,7 +306,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Currently, only the B-tree and GiST index types support multicolumn
|
||||
Currently, only the B-tree, GiST and GIN index types support multicolumn
|
||||
indexes. Up to 32 columns can be specified. (This limit can be
|
||||
altered when building <productname>PostgreSQL</productname>; see the
|
||||
file <filename>pg_config_manual.h</filename>.)
|
||||
@ -336,14 +336,21 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
|
||||
|
||||
<para>
|
||||
A multicolumn GiST index can be used with query conditions that
|
||||
involve any subset of the index's columns. Conditions on additional
|
||||
columns restrict the entries returned by the index, but the condition on
|
||||
the first column is the most important one for determining how much of
|
||||
the index needs to be scanned. A GiST index will be relatively
|
||||
ineffective if its first column has only a few distinct values, even if
|
||||
involve any subset of the index's columns. Conditions on additional
|
||||
columns restrict the entries returned by the index, but the condition on
|
||||
the first column is the most important one for determining how much of
|
||||
the index needs to be scanned. A GiST index will be relatively
|
||||
ineffective if its first column has only a few distinct values, even if
|
||||
there are many distinct values in additional columns.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A multicolumn GIN index can be used with query conditions that
|
||||
involve any subset of the index's columns. Unlike B-tree or GiST,
|
||||
index search effectiveness is the same regardless of which index column(s)
|
||||
the query conditions use.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Of course, each column must be used with operators appropriate to the index
|
||||
type; clauses that involve other operators will not be considered.
|
||||
@ -551,7 +558,7 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> automatically creates a unique
|
||||
index when a unique constraint or a primary key is defined for a table.
|
||||
The index covers the columns that make up the primary key or unique
|
||||
The index covers the columns that make up the primary key or unique
|
||||
columns (a multicolumn index, if appropriate), and is the mechanism
|
||||
that enforces the constraint.
|
||||
</para>
|
||||
@ -798,9 +805,9 @@ SELECT * FROM orders WHERE order_nr = 3501;
|
||||
or the index will not be recognized to be usable. Matching takes
|
||||
place at query planning time, not at run time. As a result,
|
||||
parameterized query clauses will not work with a partial index. For
|
||||
example a prepared query with a parameter might specify
|
||||
<quote>x < ?</quote> which will never imply
|
||||
<quote>x < 2</quote> for all possible values of the parameter.
|
||||
example a prepared query with a parameter might specify
|
||||
<quote>x < ?</quote> which will never imply
|
||||
<quote>x < 2</quote> for all possible values of the parameter.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_index.sgml,v 1.67 2008/03/16 23:57:51 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_index.sgml,v 1.68 2008/07/11 21:06:29 tgl Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -394,7 +394,7 @@ Indexes:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Currently, only the B-tree and GiST index methods support
|
||||
Currently, only the B-tree, GiST and GIN index methods support
|
||||
multicolumn indexes. Up to 32 fields can be specified by default.
|
||||
(This limit can be altered when building
|
||||
<productname>PostgreSQL</productname>.) Only B-tree currently
|
||||
@ -423,7 +423,7 @@ Indexes:
|
||||
the optional clauses <literal>ASC</>, <literal>DESC</>, <literal>NULLS
|
||||
FIRST</>, and/or <literal>NULLS LAST</> can be specified to reverse
|
||||
the normal sort direction of the index. Since an ordered index can be
|
||||
scanned either forward or backward, it is not normally useful to create a
|
||||
scanned either forward or backward, it is not normally useful to create a
|
||||
single-column <literal>DESC</> index — that sort ordering is already
|
||||
available with a regular index. The value of these options is that
|
||||
multicolumn indexes can be created that match the sort ordering requested
|
||||
|
Reference in New Issue
Block a user