122 lines
7.8 KiB
HTML
122 lines
7.8 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="Queries using SQL Query Engine" />
|
||
|
|
<meta name="abstract" content="The SQL Query Engine (SQE) provides targeted optimization for partitioned tables using dynamic partition expansion optimization." />
|
||
|
|
<meta name="description" content="The SQL Query Engine (SQE) provides targeted optimization for partitioned tables using dynamic partition expansion optimization." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="performancept.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzaf3ptcheck.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzaf3inexpt.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="rzaf3sqept" />
|
||
|
|
<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>Queries using SQL Query Engine</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzaf3sqept"><a name="rzaf3sqept"><!-- --></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">Queries using SQL Query Engine</h1>
|
||
|
|
<div><p>The SQL Query Engine (SQE) provides targeted optimization for partitioned
|
||
|
|
tables using dynamic partition expansion optimization.</p>
|
||
|
|
<p>This targeted optimization method first determines whether a given query
|
||
|
|
is structured such that certain partitions in the partitioned table would
|
||
|
|
benefit from specific optimization. If targeted optimization is warranted,
|
||
|
|
the optimizer determines which partitions can benefit from individual optimization;
|
||
|
|
those partitions are then optimized separately. The remaining partitions use
|
||
|
|
the <em>once for all</em> technique.</p>
|
||
|
|
<div class="p">The optimizer determines whether the query or table environment justifies
|
||
|
|
dynamic expansion based on the following characteristics:<ul><li>The table is range partitioned and the query involves predicate selection
|
||
|
|
against the range.</li>
|
||
|
|
<li>The table has an index over one or some of the partitions, but not all
|
||
|
|
(a <em>subpartition spanning index</em>).</li>
|
||
|
|
<li>The table has relatively few partitions.</li>
|
||
|
|
<li>Constraint definitions on the table dictate that only certain partitions
|
||
|
|
participate.</li>
|
||
|
|
<li>Estimated run time exceeds a particular threshold.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>If expansion is justified, the optimizer determines the
|
||
|
|
target partitions using existing statistic techniques as appropriate. For
|
||
|
|
example, for range partitioning and predicate selection, the optimizer looks
|
||
|
|
into the statistics or index to determine which main partitions are of interest.
|
||
|
|
When the target partitions are identified, the optimizer rewrites the query.
|
||
|
|
The targeted partitions are redefined in a UNION operation. The remaining
|
||
|
|
partitions remain as a <em>single table instance</em>. That single instance
|
||
|
|
is then added to the UNION operation along with the targeted partitions. As
|
||
|
|
soon as the rewriting is performed, the optimizer uses existing optimization
|
||
|
|
techniques to determine the plan for each UNION piece. At the end of the optimization,
|
||
|
|
the single instance is converted into another UNION operation of its contained
|
||
|
|
partitions. The optimized plan for the single instance is replicated across
|
||
|
|
the UNION subtrees, thus drastically reducing the optimization time for partitioned
|
||
|
|
tables.</p>
|
||
|
|
<p>The SQL Query Engine also uses <em>logical partition elimination</em> to
|
||
|
|
optimize partitioned tables. This method allows the optimizer to identify
|
||
|
|
potential partition elimination opportunities. The optimizer looks for opportunities
|
||
|
|
where a source table's reduced answer set can be applied to the partition
|
||
|
|
table's definition key with a join predicate. When these opportunities are
|
||
|
|
identified, the optimizer builds logic into the query run time to eliminate
|
||
|
|
partitions based on the result set of the source table.</p>
|
||
|
|
<p>For example, consider a query in which the optimizer identifies a predicate
|
||
|
|
(in this example, a WHERE clause) involving the partition key of the partition
|
||
|
|
table. If a constraint on a partition limits the key to a range from 0 to
|
||
|
|
10 and a predicate in the query identifies a key value of 11, the partition
|
||
|
|
can be logically eliminated. Note that the implementation for the partition
|
||
|
|
is still built into the query, but the path is shunted by the up-front processing
|
||
|
|
of the constraint combined with the predicate. This logic is built in for
|
||
|
|
reusability purposes. Another query with a predicate that identifies a key
|
||
|
|
value of 10 can be implemented with this plan as well. If the partition was
|
||
|
|
physically removed from the implementation, the implementation would not be
|
||
|
|
reusable.</p>
|
||
|
|
<p>Consider this more complicated example:</p>
|
||
|
|
<pre>select *
|
||
|
|
from sales, timeDim
|
||
|
|
where sales.DateId = timeDim.DateId
|
||
|
|
and timeDim.Date > '09/01/2004'</pre>
|
||
|
|
<p>In this example, <samp class="codeph">sales</samp> is a range-partitioned table where <samp class="codeph">sales.DateId</samp> is
|
||
|
|
identified as the partition key and <samp class="codeph">sales.DateId = timeDim.DateId</samp> is
|
||
|
|
identified as a potential reducing predicate. The query is modified (roughly)
|
||
|
|
as: </p>
|
||
|
|
<pre>with sourceTable as (select * from timeDim where timeDim.Date > '09/01/2004')
|
||
|
|
select *
|
||
|
|
from sales, sourceTable
|
||
|
|
where sales.DateId = sourceTable.DateId
|
||
|
|
and sales.DateId IN (select DateId from sourceTable)</pre>
|
||
|
|
<div class="p">In this example, the original join survives, but the additional local predicate, <samp class="codeph">sales.DateId
|
||
|
|
IN (select DateId from sourceTable)</samp>, is added. This new predicate
|
||
|
|
can now be combined with information about the partition definition to produce
|
||
|
|
an answer of which partitions participate. This outcome is produced because
|
||
|
|
of the following conditions:<ul><li>The existence of a join to the partitioning key.</li>
|
||
|
|
<li>The join from table can be reduced into a smaller set of join values.
|
||
|
|
These join values can then be used to shunt partitions in the partitioned
|
||
|
|
table.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="rzaf3ptcheck.htm">Check constraint optimization</a></strong><br />
|
||
|
|
The optimizer uses check constraints (either user-added or the implicit check constraints added for the partition key) to reduce the partitions examined.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="rzaf3inexpt.htm">Index usage</a></strong><br />
|
||
|
|
The SQL Query Engine (SQE) uses both partitioned and nonpartitioned indexes to implement queries.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="performancept.htm" title="Queries that reference partitioned tables need to be carefully considered because partitioned tables are often very large. It is important to understand the effects of accessing multiple partitions on your system and applications.">Query performance and optimization</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></body>
|
||
|
|
</html>
|