Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 2ce4b4c

Browse files
committed
Update obsolete statement that indexes can have only 7 columns.
Reorganize description of index features for more clarity.
1 parent ee4dcf1 commit 2ce4b4c

File tree

1 file changed

+70
-46
lines changed

1 file changed

+70
-46
lines changed

doc/src/sgml/indices.sgml

Lines changed: 70 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,21 @@
22
<title id="indices-title">Indices and Keys</title>
33

44
<para>
5-
Indexes are primarily used to enhance database
5+
Indexes are commonly used to enhance database
66
performance. They should be defined on table columns (or class
7-
attributes) which are used as qualifications in repetative queries.
7+
attributes) which are used as qualifications in repetitive queries.
88
Inappropriate use will result in slower performance, since update
99
and insertion times are increased in the presence of indices.
1010
</para>
1111

12+
<para>
13+
Indexes may also be used to enforce uniqueness of a table's primary key.
14+
When an index is declared UNIQUE, multiple table rows with identical
15+
index entries won't be allowed.
16+
For this purpose, the goal is ensuring data consistency, not improving
17+
performance, so the above caution about inappropriate use doesn't apply.
18+
</para>
19+
1220
<para>
1321
Two forms of indices may be defined:
1422

@@ -17,25 +25,20 @@
1725
<para>
1826
For a <firstterm>value index</firstterm>,
1927
the key fields for the
20-
index are specified as column names; a column may also have
21-
an associated operator class. An operator class is used
22-
to specify the operators to be used for a particular
23-
index. For example, a btree index on four-byte integers
24-
would use the <literal>int4_ops</literal> class;
25-
this operator class includes
26-
comparison functions for four-byte integers. The default
27-
operator class is the appropriate operator class for that
28-
field type.
28+
index are specified as column names; multiple columns
29+
can be specified if the index access method supports
30+
multi-column indexes.
2931
</para>
3032
</listitem>
3133

3234
<listitem>
3335
<para>
3436
For a <firstterm>functional index</firstterm>, an index is defined
35-
on the result of a user-defined function applied
37+
on the result of a function applied
3638
to one or more attributes of a single class.
37-
These functional indices
38-
can be used to obtain fast access to data
39+
This is a single-column index (namely, the function result)
40+
even if the function uses more than one input field.
41+
Functional indices can be used to obtain fast access to data
3942
based on operators that would normally require some
4043
transformation to apply them to the base data.
4144
</para>
@@ -45,8 +48,8 @@
4548

4649
<para>
4750
Postgres provides btree, rtree and hash access methods for
48-
secondary indices. The btree access method is an implementation of
49-
the Lehman-Yao high-concurrency btrees. The rtree access method
51+
indices. The btree access method is an implementation of
52+
Lehman-Yao high-concurrency btrees. The rtree access method
5053
implements standard rtrees using Guttman's quadratic split algorithm.
5154
The hash access method is an implementation of Litwin's linear
5255
hashing. We mention the algorithms used solely to indicate that all
@@ -56,8 +59,9 @@
5659
</para>
5760

5861
<para>
59-
The Postgres query optimizer will consider using btree indices in a scan
60-
whenever an indexed attribute is involved in a comparison using one of:
62+
The <productname>Postgres</productname>
63+
query optimizer will consider using a btree index whenever
64+
an indexed attribute is involved in a comparison using one of:
6165

6266
<simplelist type="inline">
6367
<member>&lt;</member>
@@ -68,19 +72,6 @@
6872
</simplelist>
6973
</para>
7074

71-
<para>
72-
Both box classes support indices on the <literal>box</literal> data
73-
type in <productname>Postgres</productname>.
74-
The difference between them is that <literal>bigbox_ops</literal>
75-
scales box coordinates down, to avoid floating point exceptions from
76-
doing multiplication, addition, and subtraction on very large
77-
floating-point coordinates. If the field on which your rectangles lie
78-
is about 20,000 units square or larger, you should use
79-
<literal>bigbox_ops</literal>.
80-
The <literal>poly_ops</literal> operator class supports rtree
81-
indices on <literal>polygon</literal> data.
82-
</para>
83-
8475
<para>
8576
The <productname>Postgres</productname>
8677
query optimizer will consider using an rtree index whenever
@@ -105,27 +96,54 @@
10596
</para>
10697

10798
<para>
108-
Currently, only the BTREE access method supports multi-column
109-
indexes. Up to 7 keys may be specified.
99+
Currently, only the btree access method supports multi-column
100+
indexes. Up to 16 keys may be specified by default (this limit
101+
can be altered when building Postgres).
110102
</para>
111103

112104
<para>
113-
Use <xref endterm="sql-dropindex-title"
114-
linkend="sql-dropindex-title">
115-
to remove an index.
116-
</para>
105+
An <firstterm>operator class</firstterm> can be specified for each
106+
column of an index. The operator class identifies the operators to
107+
be used by the index for that column. For example, a btree index on
108+
four-byte integers would use the <literal>int4_ops</literal> class;
109+
this operator class includes comparison functions for four-byte
110+
integers. In practice the default operator class for the field's
111+
datatype is usually sufficient. The main point of having operator classes
112+
is that for some datatypes, there could be more than one meaningful
113+
ordering. For an index on such a datatype, we could select which
114+
ordering we wanted by selecting the proper operator class. There
115+
are also some operator classes with special purposes:
117116

118-
<para>
119-
The <literal>int24_ops</literal>
120-
operator class is useful for constructing indices on int2 data, and
121-
doing comparisons against int4 data in query qualifications.
122-
Similarly, <literal>int42_ops</literal>
123-
support indices on int4 data that is to be compared against int2 data
124-
in queries.
117+
<itemizedlist>
118+
<listitem>
119+
<para>
120+
The operator classes <literal>box_ops</literal> and
121+
<literal>bigbox_ops</literal> both support rtree indices on the
122+
<literal>box</literal> datatype.
123+
The difference between them is that <literal>bigbox_ops</literal>
124+
scales box coordinates down, to avoid floating point exceptions from
125+
doing multiplication, addition, and subtraction on very large
126+
floating-point coordinates. If the field on which your rectangles lie
127+
is about 20,000 units square or larger, you should use
128+
<literal>bigbox_ops</literal>.
129+
</para>
130+
</listitem>
131+
132+
<listitem>
133+
<para>
134+
The <literal>int24_ops</literal>
135+
operator class is useful for constructing indices on int2 data, and
136+
doing comparisons against int4 data in query qualifications.
137+
Similarly, <literal>int42_ops</literal>
138+
support indices on int4 data that is to be compared against int2 data
139+
in queries.
140+
</para>
141+
</listitem>
142+
</itemizedlist>
125143
</para>
126144

127145
<para>
128-
The following select list returns all ops_names:
146+
The following query shows all defined operator classes:
129147

130148
<programlisting>
131149
SELECT am.amname AS acc_name,
@@ -140,6 +158,12 @@ SELECT am.amname AS acc_name,
140158
</programlisting>
141159
</para>
142160

161+
<para>
162+
Use <xref endterm="sql-dropindex-title"
163+
linkend="sql-dropindex-title">
164+
to remove an index.
165+
</para>
166+
143167
<sect1 id="keys">
144168
<title id="keys-title">Keys</title>
145169

@@ -193,7 +217,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
193217

194218
<para>
195219
So, the user selects the collection by its name. We therefore make sure,
196-
withing the database, that names are unique. However, no other table in the
220+
within the database, that names are unique. However, no other table in the
197221
database relates to the collections table by the collection Name. That
198222
would be very inefficient.
199223
</para>

0 commit comments

Comments
 (0)