88 lines
8.1 KiB
HTML
88 lines
8.1 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="concept" />
|
||
|
|
<meta name="DC.Title" content="Join optimization" />
|
||
|
|
<meta name="abstract" content="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." />
|
||
|
|
<meta name="description" content="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." />
|
||
|
|
<meta name="DC.subject" content="join, optimization" />
|
||
|
|
<meta name="keywords" content="join, optimization" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="per0001.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="c23nl.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqjoinoptalg.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqjoinorder.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="costselect.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqpredtrans.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqlpg.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqtipsdata.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqmultijoin.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzajqjoinproblems.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="perf15.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="perf24" />
|
||
|
|
<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>Join optimization</title>
|
||
|
|
</head>
|
||
|
|
<body id="perf24"><a name="perf24"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Join optimization</h1>
|
||
|
|
<div><p>A join operation is a complex function that requires special attention
|
||
|
|
in order to achieve good performance. This section describes how <span class="keyword">DB2 Universal Database™ for iSeries™</span> 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.</p>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="c23nl.htm">Nested loop join implementation</a></strong><br />
|
||
|
|
<span class="keyword">DB2 Universal Database for iSeries</span> provides
|
||
|
|
a <strong>nested loop</strong> join method. For this method, the processing of the tables
|
||
|
|
in the join are ordered. This order is called the <strong>join order</strong>. The first
|
||
|
|
table in the final join order is called the <strong>primary table</strong>. The other
|
||
|
|
tables are called <strong>secondary tables</strong>. Each join table position is called
|
||
|
|
a <strong>dial</strong>. </li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqjoinoptalg.htm">Join optimization algorithm</a></strong><br />
|
||
|
|
The query optimizer must determine the join columns, join operators, local row selection, dial implementation, and dial ordering for a join query.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqjoinorder.htm">Join order optimization</a></strong><br />
|
||
|
|
The join order is fixed if any join logical files are referenced. The join order is also fixed if the OPNQRYF JORDER(*FILE) parameter is specified or the query options file (QAQQINI) FORCE_JOIN_ORDER parameter is *YES.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="costselect.htm">Cost estimation and index selection for join secondary dials</a></strong><br />
|
||
|
|
As the query optimizer compares the various possible access choices, it must assign a numeric cost value to each candidate and use that value to determine the implementation which consumes the least amount of processing time. This costing value is a combination of CPU and I/O time</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqpredtrans.htm">Predicates generated through transitive closure</a></strong><br />
|
||
|
|
For join queries, the query optimizer may do some special processing to generate additional selection. When the set of predicates that belong to a query logically infer extra predicates, the query optimizer generates additional predicates. The purpose is to provide more information during join optimization.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqlpg.htm">Look ahead predicate generation (LPG)</a></strong><br />
|
||
|
|
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.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqtipsdata.htm">Tips for improving performance when selecting data from more than two tables</a></strong><br />
|
||
|
|
The following suggestion is only applicable to CQE and is directed specifically to select-statements that access several tables. For joins that involve more than two tables, you might want to provide redundant information about the join columns. The CQE optimizer does not generate transitive closure predicates between 2 columns. If you give the optimizer extra information to work with when requesting a join, it can determine the best way to do the join. The additional information might seem redundant, but is helpful to the optimizer.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqmultijoin.htm">Multiple join types for a query</a></strong><br />
|
||
|
|
Even though multiple join types (inner, left outer, right outer,
|
||
|
|
left exception, and right exception) can be specified in the query using the
|
||
|
|
JOIN syntax, the <span class="keyword">iSeries</span> Licensed
|
||
|
|
Internal Code can only support one join type of inner, left outer, or left
|
||
|
|
exception join type for the entire query. This requires the optimizer to determine
|
||
|
|
what the overall join type for the query should be and to reorder files to
|
||
|
|
achieve the correct semantics. </li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzajqjoinproblems.htm">Sources of join query performance problems</a></strong><br />
|
||
|
|
The optimization algorithms described above benefit most join queries, but the performance of a few queries may be degraded.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="perf15.htm">Tips for improving the performance of join queries</a></strong><br />
|
||
|
|
If you are looking at a join query which is performing poorly or you are about to create a new application which uses join queries, these tips may be useful.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="per0001.htm" title="This overview of the query optimizer provides guidelines for designing queries that will perform and will use server resources more efficiently.">Processing queries: Overview</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|