86 lines
6.2 KiB
HTML
86 lines
6.2 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="Look ahead predicate generation (LPG)" />
|
||
|
|
<meta name="abstract" content="A special type of transitive closure called look ahead predicate generation (LPG) may be costed for joins. In this case, the optimizer attempts to minimize the random I/O costs of a join by pre-applying the results of the query to a large fact table. LPG will typically be used with a class of queries referred to as star join queries, however it can possibly be used with any join query." />
|
||
|
|
<meta name="description" content="A special type of transitive closure called look ahead predicate generation (LPG) may be costed for joins. In this case, the optimizer attempts to minimize the random I/O costs of a join by pre-applying the results of the query to a large fact table. LPG will typically be used with a class of queries referred to as star join queries, however it can possibly be used with any join query." />
|
||
|
|
<meta name="DC.subject" content="look ahead predicate generation" />
|
||
|
|
<meta name="keywords" content="look ahead predicate generation" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="perf24.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="qryoptf.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="rzajqlpg" />
|
||
|
|
<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>Look ahead predicate generation (LPG)</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzajqlpg"><a name="rzajqlpg"><!-- --></a>
|
||
|
|
<img src="./delta.gif" alt="Start of change" /><!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Look ahead predicate generation (LPG)</h1>
|
||
|
|
<div><p>A special type of transitive closure called look ahead predicate
|
||
|
|
generation (LPG) may be costed for joins. In this case, the optimizer attempts
|
||
|
|
to minimize the random I/O costs of a join by pre-applying the results of
|
||
|
|
the query to a large fact table. LPG will typically be used with a class of
|
||
|
|
queries referred to as star join queries, however it can possibly be used
|
||
|
|
with any join query. </p>
|
||
|
|
<div class="section"><p>Look at the following query: </p>
|
||
|
|
<pre><strong>SELECT * FROM</strong> EMPLOYEE,EMP_ACT
|
||
|
|
<strong>WHERE</strong> EMPLOYEE.EMPNO = EMP_ACT.EMPNO
|
||
|
|
<strong>AND</strong> EMPLOYEE.EMPNO ='000010'</pre>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The optimizer may decide to internally modify the query to be: </p>
|
||
|
|
<pre><strong>WITH</strong> HT <strong>AS</strong> (<strong>SELECT</strong> *
|
||
|
|
<strong>FROM</strong> EMPLOYEE
|
||
|
|
<strong>WHERE</strong> EMPLOYEE.EMPNO='000010')
|
||
|
|
|
||
|
|
<strong>SELECT *</strong>
|
||
|
|
<strong>FROM</strong> HT, EMP_ACT
|
||
|
|
<strong>WHERE</strong> HT.EMPNO = EMP_ACT.EMPNO
|
||
|
|
<strong>AND</strong> EMP_ACT.EMPNO <strong>IN</strong> (<strong>SELECT DISTINCT</strong> EMPNO
|
||
|
|
<strong>FROM</strong> HT)</pre>
|
||
|
|
</div>
|
||
|
|
<div class="section"><p>The optimizer places the results of the "subquery" into a temporary
|
||
|
|
hash table. The hash table of the subquery can be applied in one of two methods
|
||
|
|
against the EMP_ACT (fact) table:</p>
|
||
|
|
<ul><li>The distinct values of the hash tables are retrieved. For each distinct
|
||
|
|
value, an index over EMP_ACT is probed to determine which records are returned
|
||
|
|
for that value. Those record identifiers are normally then stored and sorted
|
||
|
|
(sometimes the sorting is omitted, depending on the total number of record
|
||
|
|
ids expected). Once the ids are determined, those subset of EMP_ACT records
|
||
|
|
can then be accessed in a way much more efficient than in a traditional nested
|
||
|
|
loop join processing. </li>
|
||
|
|
<li>EMP_ACT can be scanned. For each record, the hash table is probed to see
|
||
|
|
if the record will join at all to EMPLOYEE. This allows for efficient access
|
||
|
|
to EMP_ACT with a more efficient record rejection method than in a traditional
|
||
|
|
nested loop join process.</li>
|
||
|
|
</ul>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> LPG processing is part of the normal processing in the SQL Query
|
||
|
|
Engine. Classic Query Engine only considers the first method, requires that
|
||
|
|
the index in question by an EVI and also requires use of the STAR_JOIN and
|
||
|
|
FORCE_JOIN_ORDER QAQQINI options.</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="perf24.htm" title="A join operation is a complex function that requires special attention in order to achieve good performance. This section describes how DB2 Universal Database for iSeries implements join queries and how optimization choices are made by the query optimizer. It also describes design tips and techniques which help avoid or solve performance problems.">Join optimization</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relref"><strong>Related reference</strong><br />
|
||
|
|
<div><a href="qryoptf.htm" title="The query options file QAQQINI support provides the ability to dynamically modify or override the environment in which queries are executed through the Change Query Attributes (CHGQRYA) command and the QAQQINI file. The query options file QAQQINI is used to set some attributes used by the database manager.">Control queries dynamically with the query options file QAQQINI</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></body>
|
||
|
|
</html>
|