173 lines
11 KiB
HTML
173 lines
11 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="reference" />
|
||
|
|
<meta name="DC.Title" content="Radix index probe" />
|
||
|
|
<meta name="abstract" content="A radix index probe operation is used to retrieve the rows from a table in a keyed sequence. The main difference between the Radix Index Probe and the Radix Index Scan is that the rows being returned must first be identified by a probe operation to subset the rows being retrieved." />
|
||
|
|
<meta name="description" content="A radix index probe operation is used to retrieve the rows from a table in a keyed sequence. The main difference between the Radix Index Probe and the Radix Index Scan is that the rows being returned must first be identified by a probe operation to subset the rows being retrieved." />
|
||
|
|
<meta name="DC.subject" content="definitions, radix index probe, index, index probe access method, access method" />
|
||
|
|
<meta name="keywords" content="definitions, radix index probe, index, index probe access method, access method" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="perf21b.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="c23nl.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="ipuc.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzajqrinprobe" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Radix index probe</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzajqrinprobe"><a name="rzajqrinprobe"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Radix index probe</h1>
|
||
|
|
<div><p>A radix index probe operation is used to retrieve the rows from
|
||
|
|
a table in a keyed sequence. The main difference between the Radix Index Probe
|
||
|
|
and the Radix Index Scan is that the rows being returned must first be identified
|
||
|
|
by a probe operation to subset the rows being retrieved.</p>
|
||
|
|
<div class="section"><p>The optimizer attempts to match the columns used for some or all
|
||
|
|
of the selection against the leading keys of the index. It then rewrites
|
||
|
|
the selection into a series of ranges that can be used to probe directly into
|
||
|
|
the index's key values. Only those keys from the series of ranges are paged
|
||
|
|
into main memory. The resulting row numbers generated by the probe operation
|
||
|
|
can then be further processed by any remaining selection against the index
|
||
|
|
keys or a Table Probe operation. This provides for very quick access to only
|
||
|
|
the rows of the index that satisfy the selection.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>While the main function of a radix index probe is to provide a
|
||
|
|
form of quick selection against the index keys, the sequencing of the rows
|
||
|
|
can still be used by the optimizer to satisfy other portions of the query
|
||
|
|
(such as ordering or grouping). Since the I/Os associated with the index
|
||
|
|
will only be for those index rows that match the selection, no extraneous
|
||
|
|
processing will be performed on those rows that do not match the probe selection.
|
||
|
|
This savings in I/Os against rows that are not a part of the result set for
|
||
|
|
the query, is one of the primary advantages for this operation.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section">
|
||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 1. Radix index probe attributes</caption><thead align="left"><tr><th valign="top" width="31.122448979591837%" id="d0e50">Data access method</th>
|
||
|
|
<th valign="top" width="68.87755102040816%" id="d0e52">Radix index probe</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Description</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 ">The index is quickly probed based upon the selection
|
||
|
|
criteria that were rewritten into a series of ranges. Only those keys that
|
||
|
|
satisfy the selection will be used to generate a table row number. </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Advantages</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 "><ul><li>Only those index entries that match any selection continue to be processed </li>
|
||
|
|
<li>Provides very quick access to the selected rows </li>
|
||
|
|
<li>Potential to extract all of the data from the index keys' values, thus
|
||
|
|
eliminating the need for a Table Probe</li>
|
||
|
|
<li>Returns the rows back in a sequence based upon the keys of the index</li>
|
||
|
|
</ul>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Considerations</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 ">Generally requires a Table Probe to be performed to
|
||
|
|
extract any remaining columns required to satisfy the query. Can perform poorly
|
||
|
|
when a large number of rows are selected because of the random I/O associated
|
||
|
|
with the Table Probe. </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Likely to be used</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 "><ul><li>When asking for or expecting only a few rows to be returned from the index</li>
|
||
|
|
<li>When sequencing the rows is required the query (for example, ordering
|
||
|
|
or grouping) </li>
|
||
|
|
<li>When the selection columns match the leading key columns of the index </li>
|
||
|
|
</ul>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Example SQL statement</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 "><pre>CREATE INDEX X1 ON Employee (LastName, WorkDept)
|
||
|
|
|
||
|
|
SELECT * FROM Employee
|
||
|
|
WHERE WorkDept BETWEEN 'A01' AND 'E01'
|
||
|
|
AND LastName IN ('Smith', 'Jones', 'Peterson')
|
||
|
|
OPTIMIZE FOR ALL ROWS</pre>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Messages indicating use</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 "><ul><li>Optimizer Debug: <pre> CPI4328 -- Access path of file X1 was used by query.</pre>
|
||
|
|
</li>
|
||
|
|
<li>PRTSQLINF: <pre>SQL4008 -- Index X1 used for table 1.
|
||
|
|
SQL4011 -- Index scan-key row positioning used
|
||
|
|
on table 1.</pre>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>SMP parallel enabled</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 ">Yes</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Also referred to as</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 ">Index Probe <p>Index Probe, Preload</p>
|
||
|
|
<p>Index Probe,
|
||
|
|
Distinct</p>
|
||
|
|
<p>Index Probe Distinct, Preload</p>
|
||
|
|
<p>Index Probe, Key Positioning</p>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" width="31.122448979591837%" headers="d0e50 "><strong>Visual Explain icon</strong></td>
|
||
|
|
<td valign="top" width="68.87755102040816%" headers="d0e52 "><br /><img src="rzajq508.gif" alt="Radix index probe icon" /><br /></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p> The following example illustrates a query where the optimizer
|
||
|
|
might choose the radix index probe access method: </p>
|
||
|
|
<pre> CREATE INDEX X1 ON Employee (LastName, WorkDept)
|
||
|
|
|
||
|
|
SELECT * FROM Employee
|
||
|
|
WHERE WorkDept BETWEEN 'A01' AND 'E01'
|
||
|
|
AND LastName IN ('Smith', 'Jones', 'Peterson')
|
||
|
|
OPTIMIZE FOR ALL ROWS</pre>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p> In this example, the optimizer uses the index X1 to position
|
||
|
|
(probe) to the first index entry that matches the selection built over both
|
||
|
|
the LastName and WorkDept columns. The selection is rewritten into a series
|
||
|
|
of ranges that match all of the leading key columns used from the index X1.
|
||
|
|
The probe is then based upon the composite concatenated values for all of
|
||
|
|
the leading keys. The pseudo-SQL for this rewritten SQL might look as follows: </p>
|
||
|
|
<pre> SELECT * FROM X1
|
||
|
|
WHERE X1.LeadingKeys BETWEEN 'JonesA01' AND 'JonesE01'
|
||
|
|
OR X1.LeadingKeys BETWEEN 'PetersonA01' AND 'PetersonE01'
|
||
|
|
OR X1.LeadingKeys BETWEEN 'SmithA01' AND 'SmithE01'</pre>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>All of the key entries that satisfy the probe operation will then
|
||
|
|
be used to generate a row number for the table associated with the index (for
|
||
|
|
example, Employee). The row number will be used by a Table Probe operation
|
||
|
|
to perform random I/O on the table to produce the results for the query. This
|
||
|
|
processing continues until all of the rows that satisfy the index probe operation
|
||
|
|
have been processed. Note that in this example, all of the index entries
|
||
|
|
processed and rows retrieved met the index probe criteria. If additional selection
|
||
|
|
were added that cannot be performed through an index probe operation (such
|
||
|
|
as selection against columns which are not a part of the leading key columns
|
||
|
|
of the index), the optimizer will perform an index scan operation within the
|
||
|
|
range of probed values. This still allows for selection to be performed before
|
||
|
|
the Table Probe operation.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="perf21b.htm" title="An SQL index (or keyed sequence access path) is a permanent object that is created over a table and used by the optimizer to provide a sequenced view of the data for a scan or probe operation.">Radix index</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="c23nl.htm" title="DB2 Universal Database for iSeries provides a nested loop join method. For this method, the processing of the tables in the join are ordered. This order is called the join order. The first table in the final join order is called the primary table. The other tables are called secondary tables. Each join table position is called a dial.">Nested loop join implementation</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relref"><strong>Related reference</strong><br />
|
||
|
|
<div><a href="ipuc.htm" title="Some complex queries can perform better by using a sort or hashing method to evaluate the query instead of using or creating an index.">Effects of the ALWCPYDTA parameter on database performance</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|