143 lines
8.6 KiB
HTML
143 lines
8.6 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="Hash table probe" />
|
||
|
<meta name="abstract" content="A hash table probe operation is used to retrieve rows from a temporary hash table based upon a probe lookup operation." />
|
||
|
<meta name="description" content="A hash table probe operation is used to retrieve rows from a temporary hash table based upon a probe lookup operation." />
|
||
|
<meta name="DC.subject" content="definitions, hash table probe access method, hash table, probe access method, access method, hash table probe" />
|
||
|
<meta name="keywords" content="definitions, hash table probe access method, hash table, probe access method, access method, hash table probe" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzajqtemphash.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="c23nl.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="rzajqhtblprobe" />
|
||
|
<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>Hash table probe</title>
|
||
|
</head>
|
||
|
<body id="rzajqhtblprobe"><a name="rzajqhtblprobe"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Hash table probe</h1>
|
||
|
<div><p>A hash table probe operation is used to retrieve rows from a temporary
|
||
|
hash table based upon a probe lookup operation.</p>
|
||
|
<div class="section"><p>The optimizer initially identifies the keys of the temporary hash
|
||
|
table from the join criteria specified in the query. This is done so that
|
||
|
when the hash table probe is performed, the values used to probe into the
|
||
|
temporary hash table will be extracted from the join-from criteria specified
|
||
|
in the selection. Those values will be sent through the same hashing algorithm
|
||
|
used to populate the temporary hash table in order to determine if any rows
|
||
|
have a matching (equal) value. All of the matching join rows are then returned
|
||
|
to be further processed by the query.</p>
|
||
|
</div>
|
||
|
<div class="section">
|
||
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 1. Hash table probe attributes</caption><thead align="left"><tr><th valign="top" width="31.472081218274113%" id="d0e40">Data access method</th>
|
||
|
<th valign="top" width="68.52791878172589%" id="d0e42">Hash table probe</th>
|
||
|
</tr>
|
||
|
</thead>
|
||
|
<tbody><tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Description</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 ">The temporary hash table is quickly probed based upon
|
||
|
the join criteria. </td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Advantages</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 "><ul><li>Provides very quick access to the selected rows that match probe criteria</li>
|
||
|
<li>Reduces the random I/O to the table generally associated with longer running
|
||
|
queries that use an index to collate the data</li>
|
||
|
<li>Selection can be performed before generating the hash table to subset
|
||
|
the number of rows in the temporary object</li>
|
||
|
</ul>
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Considerations</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 ">Generally used to process equal join criteria. Can perform
|
||
|
poorly when the entire hash table does not stay resident in memory as it is
|
||
|
being processed.</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Likely to be used</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 "><ul><li>When the use of temporary results is allowed by the query environmental
|
||
|
parameter (ALWCPYDTA)</li>
|
||
|
<li>When the data is required to be collated based upon a column or columns
|
||
|
for join processing</li>
|
||
|
<li>The join criteria was specified using an equals (=) operator</li>
|
||
|
</ul>
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Example SQL statement</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 "><pre>SELET * FROM Employee XXX, Department YYY
|
||
|
WHERE XXX.WorkDept = YYY.DeptNbr
|
||
|
OPTIMIZE FOR ALL ROWS</pre>
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Messages indicating use</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 ">There are multiple ways in which a hash probe can be
|
||
|
indicated through the messages. The messages in this example illustrate how
|
||
|
the SQL Query Engine will indicate a hash probe was used. <ul><li>Optimizer Debug: <pre> CPI4327 -- File EMPLOYEE processed in join
|
||
|
position 1.
|
||
|
CPI4327 -- File DEPARTMENT processed in join
|
||
|
position 2.</pre>
|
||
|
</li>
|
||
|
<li>PRTSQLINF: <pre> SQL4007 -- Query implementation for join
|
||
|
position 1 table 1.
|
||
|
SQL4010 -- Table scan access for table 1.
|
||
|
SQL4007 -- Query implementation for join
|
||
|
position 2 table 2.
|
||
|
SQL4010 -- Table scan access for table 2.</pre>
|
||
|
</li>
|
||
|
</ul>
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>SMP parallel enabled</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 ">Yes</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Also referred to as</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 ">Hash Table Probe, Preload <p>Hash Table Probe Distinct</p>
|
||
|
<p>Hash
|
||
|
Table Probe Distinct, Preload</p>
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" width="31.472081218274113%" headers="d0e40 "><strong>Visual Explain icon</strong></td>
|
||
|
<td valign="top" width="68.52791878172589%" headers="d0e42 "><br /><img src="rzajq514.gif" alt="Hash table probe icon" /><br /></td>
|
||
|
</tr>
|
||
|
</tbody>
|
||
|
</table>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div class="section"><p>The hash table probe access method is generally considered when
|
||
|
determining the implementation for a secondary table of a join. The hash table
|
||
|
is created with the key columns that match the equal selection or join criteria
|
||
|
for the underlying table. The hash table probe allows the optimizer to choose
|
||
|
the most efficient implementation to select the rows from the underlying table
|
||
|
without regard for any join criteria. This single pass through the underlying
|
||
|
table can now choose to perform a Table Scan or use an existing index to select
|
||
|
the rows needed for the hash table population.</p>
|
||
|
</div>
|
||
|
<div class="section"><p>Since hash tables are constructed so that the majority of the
|
||
|
hash table will remain resident within main memory, the I/O associated with
|
||
|
a hash probe is minimal. Additionally, if the hash table was populated with
|
||
|
all necessary columns from the underlying table, no additional Table Probe
|
||
|
will be required to finish processing this table, once again causing further
|
||
|
I/O savings.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajqtemphash.htm" title="The temporary hash table is a temporary object that allows the optimizer to collate the rows based upon a column or set of columns. The hash table can be either scanned or probed by the optimizer to satisfy different operations of the query.">Temporary hash table</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>
|
||
|
</body>
|
||
|
</html>
|