File: indexes-types.html

package info (click to toggle)
pgadmin3 1.4.3-2
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 29,796 kB
  • ctags: 10,758
  • sloc: cpp: 55,356; sh: 6,164; ansic: 1,520; makefile: 576; sql: 482; xml: 100; perl: 18
file content (134 lines) | stat: -rw-r--r-- 7,268 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11.2.Index Types</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="indexes.html" title="Chapter11.Indexes">
<link rel="prev" href="indexes.html" title="Chapter11.Indexes">
<link rel="next" href="indexes-multicolumn.html" title="11.3.Multicolumn Indexes">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="indexes-types"></a>11.2.Index Types</h2></div></div></div>
<p>   <span class="productname">PostgreSQL</span> provides several index types:
   B-tree, R-tree, Hash, and GiST.  Each index type uses a different
   algorithm that is best suited to different types of queries.
   By default, the <code class="command">CREATE INDEX</code> command will create a
   B-tree index, which fits the most common situations.
  </p>
<p>   <a name="id627817"></a>
   <a name="id627827"></a>
   B-trees can handle equality and range queries on data that can be sorted
   into some ordering.
   In particular, the <span class="productname">PostgreSQL</span> query planner
   will consider using a B-tree index whenever an indexed column is
   involved in a comparison using one of these operators:

   </p>
<table class="simplelist" border="0" summary="Simple list">
<tr><td><code class="literal">&lt;</code></td></tr>
<tr><td><code class="literal">&lt;=</code></td></tr>
<tr><td><code class="literal">=</code></td></tr>
<tr><td><code class="literal">&gt;=</code></td></tr>
<tr><td><code class="literal">&gt;</code></td></tr>
</table>
<p>

   Constructs equivalent to combinations of these operators, such as
   <code class="literal">BETWEEN</code> and <code class="literal">IN</code>, can also be implemented with
   a B-tree index search.  (But note that <code class="literal">IS NULL</code> is not
   equivalent to <code class="literal">=</code> and is not indexable.)
  </p>
<p>   The optimizer can also use a B-tree index for queries involving the
   pattern matching operators <code class="literal">LIKE</code> and <code class="literal">~</code>
   <span class="emphasis"><em>if</em></span> the pattern is a constant and is anchored to
   the beginning of the string [mdash ] for example, <code class="literal">col LIKE
   'foo%'</code> or <code class="literal">col ~ '^foo'</code>, but not
   <code class="literal">col LIKE '%bar'</code>. However, if your server does not
   use the C locale you will need to create the index with a special
   operator class to support indexing of pattern-matching queries. See
   <a href="indexes-opclass.html" title="11.8.Operator Classes">Section11.8, &#8220;Operator Classes&#8221;</a> below. It is also possible to use
   B-tree indexes for <code class="literal">ILIKE</code> and
   <code class="literal">~*</code>, but only if the pattern starts with
   non-alphabetic characters, i.e. characters that are not affected by
   upper/lower case conversion.
  </p>
<p>   <a name="id627986"></a>
   <a name="id627996"></a>
   R-tree indexes are suited for queries on two-dimensional spatial data.
   To create an R-tree index, use a command of the form
</p>
<pre class="synopsis">CREATE INDEX <em class="replaceable"><code>name</code></em> ON <em class="replaceable"><code>table</code></em> USING rtree (<em class="replaceable"><code>column</code></em>);</pre>
<p>
   The <span class="productname">PostgreSQL</span> query planner will
   consider using an R-tree index whenever an indexed column is
   involved in a comparison using one of these operators:

   </p>
<table class="simplelist" border="0" summary="Simple list">
<tr><td><code class="literal">&lt;&lt;</code></td></tr>
<tr><td><code class="literal">&amp;&lt;</code></td></tr>
<tr><td><code class="literal">&amp;&gt;</code></td></tr>
<tr><td><code class="literal">&gt;&gt;</code></td></tr>
<tr><td><code class="literal">&lt;&lt;|</code></td></tr>
<tr><td><code class="literal">&amp;&lt;|</code></td></tr>
<tr><td><code class="literal">|&amp;&gt;</code></td></tr>
<tr><td><code class="literal">|&gt;&gt;</code></td></tr>
<tr><td><code class="literal">~</code></td></tr>
<tr><td><code class="literal">@</code></td></tr>
<tr><td><code class="literal">~=</code></td></tr>
<tr><td><code class="literal">&amp;&amp;</code></td></tr>
</table>
<p>

   (See <a href="functions-geometry.html" title="9.10.Geometric Functions and Operators">Section9.10, &#8220;Geometric Functions and Operators&#8221;</a> for the meaning of
   these operators.)
  </p>
<p>   <a name="id628127"></a>
   <a name="id628137"></a>
   Hash indexes can only handle simple equality comparisons.
   The query planner will consider using a hash index whenever an
   indexed column is involved in a comparison using the
   <code class="literal">=</code> operator.  The following command is used to
   create a hash index:
</p>
<pre class="synopsis">CREATE INDEX <em class="replaceable"><code>name</code></em> ON <em class="replaceable"><code>table</code></em> USING hash (<em class="replaceable"><code>column</code></em>);</pre>
<p>
  </p>
<p>   GiST indexes are not a single kind of index, but rather an infrastructure
   within which many different indexing strategies can be implemented.
   Accordingly, the particular operators with which a GiST index can be
   used vary depending on the indexing strategy (the <em class="firstterm">operator
   class</em>).  The standard distribution of
   <span class="productname">PostgreSQL</span> includes GiST operator classes
   equivalent to the R-tree operator classes, and many other GiST operator
   classes are available in the <code class="literal">contrib</code> collection or as separate
   projects.  For more information see <a href="gist.html" title="Chapter49.GiST Indexes">Chapter49, <i>GiST Indexes</i></a>.
  </p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>    Testing has shown <span class="productname">PostgreSQL</span>'s hash
    indexes to perform no better than B-tree indexes, and the
    index size and build time for hash indexes is much worse.
    Furthermore, hash index operations are not presently WAL-logged,
    so hash indexes may need to be rebuilt with <code class="command">REINDEX</code>
    after a database crash.
    For these reasons, hash index use is presently discouraged.
   </p>
<p>    Similarly, R-tree indexes do not seem to have any performance
    advantages compared to the equivalent operations of GiST indexes.
    Like hash indexes, they are not WAL-logged and may need
    reindexing after a database crash.
   </p>
<p>    While the problems with hash indexes may be fixed eventually,
    it is likely that the R-tree index type will be retired in a future
    release.  Users are encouraged to migrate applications that use R-tree
    indexes to GiST indexes.
   </p>
</div>
</div></body>
</html>