File: index-functions.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 (186 lines) | stat: -rw-r--r-- 10,479 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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>48.2.Index Access Method Functions</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="indexam.html" title="Chapter48.Index Access Method Interface Definition">
<link rel="prev" href="indexam.html" title="Chapter48.Index Access Method Interface Definition">
<link rel="next" href="index-scanning.html" title="48.3.Index Scanning">
<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="index-functions"></a>48.2.Index Access Method Functions</h2></div></div></div>
<p>   The index construction and maintenance functions that an index access
   method must provide are:
  </p>
<pre class="programlisting">void
ambuild (Relation heapRelation,
         Relation indexRelation,
         IndexInfo *indexInfo);</pre>
<p>
   Build a new index.  The index relation has been physically created,
   but is empty.  It must be filled in with whatever fixed data the
   access method requires, plus entries for all tuples already existing
   in the table.  Ordinarily the <code class="function">ambuild</code> function will call
   <code class="function">IndexBuildHeapScan()</code> to scan the table for existing tuples
   and compute the keys that need to be inserted into the index.
  </p>
<pre class="programlisting">bool
aminsert (Relation indexRelation,
          Datum *values,
          bool *isnull,
          ItemPointer heap_tid,
          Relation heapRelation,
          bool check_uniqueness);</pre>
<p>
   Insert a new tuple into an existing index.  The <code class="literal">values</code> and
   <code class="literal">isnull</code> arrays give the key values to be indexed, and
   <code class="literal">heap_tid</code> is the TID to be indexed.
   If the access method supports unique indexes (its
   <code class="structname">pg_am</code>.<code class="structfield">amcanunique</code> flag is true) then
   <code class="literal">check_uniqueness</code> may be true, in which case the access method
   must verify that there is no conflicting row; this is the only situation in
   which the access method normally needs the <code class="literal">heapRelation</code>
   parameter.  See <a href="index-unique-checks.html" title="48.5.Index Uniqueness Checks">Section48.5, &#8220;Index Uniqueness Checks&#8221;</a> for details.
   The result is TRUE if an index entry was inserted, FALSE if not. (A FALSE
   result does not denote an error condition, but is used for cases such
   as an index AM refusing to index a NULL.)
  </p>
<pre class="programlisting">IndexBulkDeleteResult *
ambulkdelete (Relation indexRelation,
              IndexBulkDeleteCallback callback,
              void *callback_state);</pre>
<p>
   Delete tuple(s) from the index.  This is a &#8220;<span class="quote">bulk delete</span>&#8221; operation
   that is intended to be implemented by scanning the whole index and checking
   each entry to see if it should be deleted.
   The passed-in <code class="literal">callback</code> function may be called, in the style
   <code class="literal">callback(<em class="replaceable"><code>TID</code></em>, callback_state) returns bool</code>,
   to determine whether any particular index entry, as identified by its
   referenced TID, is to be deleted.  Must return either NULL or a palloc'd
   struct containing statistics about the effects of the deletion operation.
  </p>
<pre class="programlisting">IndexBulkDeleteResult *
amvacuumcleanup (Relation indexRelation,
                 IndexVacuumCleanupInfo *info,
                 IndexBulkDeleteResult *stats);</pre>
<p>
   Clean up after a <code class="command">VACUUM</code> operation (one or more
   <code class="function">ambulkdelete</code> calls).  An index access method does not have
   to provide this function (if so, the entry in <code class="structname">pg_am</code> must
   be zero).  If it is provided, it is typically used for bulk cleanup
   such as reclaiming empty index pages.  <code class="literal">info</code>
   provides some additional arguments such as a message level for statistical
   reports, and <code class="literal">stats</code> is whatever the last
   <code class="function">ambulkdelete</code> call returned.  <code class="function">amvacuumcleanup</code>
   may replace or modify this struct before returning it.  If the result
   is not NULL it must be a palloc'd struct.  The statistics it contains
   will be reported by <code class="command">VACUUM</code> if <code class="literal">VERBOSE</code> is given.
  </p>
<p>   The purpose of an index, of course, is to support scans for tuples matching
   an indexable <code class="literal">WHERE</code> condition, often called a
   <em class="firstterm">qualifier</em> or <em class="firstterm">scan key</em>.  The semantics of
   index scanning are described more fully in <a href="index-scanning.html" title="48.3.Index Scanning">Section48.3, &#8220;Index Scanning&#8221;</a>,
   below.  The scan-related functions that an index access method must provide
   are:
  </p>
<pre class="programlisting">IndexScanDesc
ambeginscan (Relation indexRelation,
             int nkeys,
             ScanKey key);</pre>
<p>
   Begin a new scan.  The <code class="literal">key</code> array (of length <code class="literal">nkeys</code>)
   describes the scan key(s) for the index scan.  The result must be a
   palloc'd struct. For implementation reasons the index access method
   <span class="emphasis"><em>must</em></span> create this struct by calling
   <code class="function">RelationGetIndexScan()</code>.  In most cases
   <code class="function">ambeginscan</code> itself does little beyond making that call;
   the interesting parts of index-scan startup are in <code class="function">amrescan</code>.
  </p>
<pre class="programlisting">boolean
amgettuple (IndexScanDesc scan,
            ScanDirection direction);</pre>
<p>
   Fetch the next tuple in the given scan, moving in the given
   direction (forward or backward in the index).  Returns TRUE if a tuple was
   obtained, FALSE if no matching tuples remain.  In the TRUE case the tuple
   TID is stored into the <code class="literal">scan</code> structure.  Note that
   &#8220;<span class="quote">success</span>&#8221; means only that the index contains an entry that matches
   the scan keys, not that the tuple necessarily still exists in the heap or
   will pass the caller's snapshot test.
  </p>
<pre class="programlisting">boolean
amgetmulti (IndexScanDesc scan,
            ItemPointer tids,
            int32 max_tids,
            int32 *returned_tids);</pre>
<p>
   Fetch multiple tuples in the given scan.  Returns TRUE if the scan should
   continue, FALSE if no matching tuples remain.  <code class="literal">tids</code> points to
   a caller-supplied array of <code class="literal">max_tids</code>
   <code class="structname">ItemPointerData</code> records, which the call fills with TIDs of
   matching tuples.  <code class="literal">*returned_tids</code> is set to the number of TIDs
   actually returned.  This can be less than <code class="literal">max_tids</code>, or even
   zero, even when the return value is TRUE.  (This provision allows the
   access method to choose the most efficient stopping points in its scan,
   for example index page boundaries.)  <code class="function">amgetmulti</code> and
   <code class="function">amgettuple</code> cannot be used in the same index scan; there
   are other restrictions too when using <code class="function">amgetmulti</code>, as explained
   in <a href="index-scanning.html" title="48.3.Index Scanning">Section48.3, &#8220;Index Scanning&#8221;</a>.
  </p>
<pre class="programlisting">void
amrescan (IndexScanDesc scan,
          ScanKey key);</pre>
<p>
   Restart the given scan, possibly with new scan keys (to continue using
   the old keys, NULL is passed for <code class="literal">key</code>).  Note that it is not
   possible for the number of keys to be changed.  In practice the restart
   feature is used when a new outer tuple is selected by a nested-loop join
   and so a new key comparison value is needed, but the scan key structure
   remains the same.  This function is also called by
   <code class="function">RelationGetIndexScan()</code>, so it is used for initial setup
   of an index scan as well as rescanning.
  </p>
<pre class="programlisting">void
amendscan (IndexScanDesc scan);</pre>
<p>
   End a scan and release resources.  The <code class="literal">scan</code> struct itself
   should not be freed, but any locks or pins taken internally by the
   access method must be released.
  </p>
<pre class="programlisting">void
ammarkpos (IndexScanDesc scan);</pre>
<p>
   Mark current scan position.  The access method need only support one
   remembered scan position per scan.
  </p>
<pre class="programlisting">void
amrestrpos (IndexScanDesc scan);</pre>
<p>
   Restore the scan to the most recently marked position.
  </p>
<pre class="programlisting">void
amcostestimate (PlannerInfo *root,
                IndexOptInfo *index,
                List *indexQuals,
                Cost *indexStartupCost,
                Cost *indexTotalCost,
                Selectivity *indexSelectivity,
                double *indexCorrelation);</pre>
<p>
   Estimate the costs of an index scan.  This function is described fully
   in <a href="index-cost-estimation.html" title="48.6.Index Cost Estimation Functions">Section48.6, &#8220;Index Cost Estimation Functions&#8221;</a>, below.
  </p>
<p>   By convention, the <code class="literal">pg_proc</code> entry for any index
   access method function should show the correct number of arguments,
   but declare them all as type <code class="type">internal</code> (since most of the arguments
   have types that are not known to SQL, and we don't want users calling
   the functions directly anyway).  The return type is declared as
   <code class="type">void</code>, <code class="type">internal</code>, or <code class="type">boolean</code> as appropriate.
  </p>
</div></body>
</html>