2
2
<title id="indices-title">Indices and Keys</title>
3
3
4
4
<para>
5
- Indexes are primarily used to enhance database
5
+ Indexes are commonly used to enhance database
6
6
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.
8
8
Inappropriate use will result in slower performance, since update
9
9
and insertion times are increased in the presence of indices.
10
10
</para>
11
11
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
+
12
20
<para>
13
21
Two forms of indices may be defined:
14
22
17
25
<para>
18
26
For a <firstterm>value index</firstterm>,
19
27
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.
29
31
</para>
30
32
</listitem>
31
33
32
34
<listitem>
33
35
<para>
34
36
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
36
38
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
39
42
based on operators that would normally require some
40
43
transformation to apply them to the base data.
41
44
</para>
45
48
46
49
<para>
47
50
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
50
53
implements standard rtrees using Guttman's quadratic split algorithm.
51
54
The hash access method is an implementation of Litwin's linear
52
55
hashing. We mention the algorithms used solely to indicate that all
56
59
</para>
57
60
58
61
<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:
61
65
62
66
<simplelist type="inline">
63
67
<member><</member>
68
72
</simplelist>
69
73
</para>
70
74
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
-
84
75
<para>
85
76
The <productname>Postgres</productname>
86
77
query optimizer will consider using an rtree index whenever
105
96
</para>
106
97
107
98
<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).
110
102
</para>
111
103
112
104
<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:
117
116
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>
125
143
</para>
126
144
127
145
<para>
128
- The following select list returns all ops_names :
146
+ The following query shows all defined operator classes :
129
147
130
148
<programlisting>
131
149
SELECT am.amname AS acc_name,
@@ -140,6 +158,12 @@ SELECT am.amname AS acc_name,
140
158
</programlisting>
141
159
</para>
142
160
161
+ <para>
162
+ Use <xref endterm="sql-dropindex-title"
163
+ linkend="sql-dropindex-title">
164
+ to remove an index.
165
+ </para>
166
+
143
167
<sect1 id="keys">
144
168
<title id="keys-title">Keys</title>
145
169
@@ -193,7 +217,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
193
217
194
218
<para>
195
219
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
197
221
database relates to the collections table by the collection Name. That
198
222
would be very inefficient.
199
223
</para>
0 commit comments