ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzajq_5.4.0.1/rzajqrctepredicate.htm

97 lines
6.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="Predicate Pushing" />
<meta name="abstract" content="When processing most queries with a non-recursive common table expressions or views, local predicates specified on the main query are pushed down so fewer records need to be materialized. Pushing local predicates from the main query in to the defined recursive part of the query (through the Union ALL), however, may considerably alter the process of recursion itself. So as a general rule, the Union All specified in a recursive query is currently a predicate fence and predicates are not pushed down or up, through this fence." />
<meta name="description" content="When processing most queries with a non-recursive common table expressions or views, local predicates specified on the main query are pushed down so fewer records need to be materialized. Pushing local predicates from the main query in to the defined recursive part of the query (through the Union ALL), however, may considerably alter the process of recursion itself. So as a general rule, the Union All specified in a recursive query is currently a predicate fence and predicates are not pushed down or up, through this fence." />
<meta name="DC.Relation" scheme="URI" content="rzajqrecursive.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="rzajqrctepredicate" />
<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>Predicate Pushing</title>
</head>
<body id="rzajqrctepredicate"><a name="rzajqrctepredicate"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Predicate Pushing</h1>
<div><p>When processing most queries with a non-recursive common table
expressions or views, local predicates specified on the main query are pushed
down so fewer records need to be materialized. Pushing local predicates from
the main query in to the defined recursive part of the query (through the
Union ALL), however, may considerably alter the process of recursion
itself. So as a general rule, the Union All specified in a recursive query
is currently a predicate fence and predicates are not pushed down or up, through
this fence.</p>
<div class="section"><p>The following is an example of how pushing a predicate in to the
recursion limits the recursive results and alter the intent of the query.</p>
</div>
<div class="example">If the intent of the query is to find all destinations accessible
from 'Chicago' but do not include the final destinations of 'Dallas', pushing
the "arrival&lt;&gt;'Dallas'" predicate in to the recursive query alters the
output of the intended results, preventing the output of final destinations
that are not 'Dallas' but where 'Dallas' was an intermediate stop. <pre><strong>WITH</strong> destinations (departure, arrival, connects, cost ) <strong>AS</strong>
(
<strong>SELECT</strong> f.departure,f.arrival, 0, ticket
<strong>FROM</strong> flights f
<strong>WHERE</strong> f.departure='Chicago'
<strong>UNION ALL</strong>
<strong>SELECT</strong>
r.departure, b.arrival, r.connects + 1 ,
r.cost + b.ticket
<strong>FROM</strong> destinations r, flights b
<strong>WHERE</strong> r.arrival=b.departure
)
<strong>SELECT</strong> departure, arrival, connects, cost
<strong>FROM</strong> destinations
<strong>WHERE</strong> arrival != 'Dallas'
</pre>
<p>Conversely, the following is an example where a local predicate
applied to all the recursive results is a good predicate to put in the body
of the recursive definition because it may greatly decrease the amount of
rows materialized from the RCTE/View. The better query request here is to
specify the r.connects &lt;=3 local predicate with in the RCTE definition,
in the iterative fullselect.</p>
<pre><strong>WITH</strong> destinations (departure, arrival, connects, cost ) <strong>AS</strong>
(
<strong>SELECT</strong> f.departure,f.arrival, 0, ticket
<strong>FROM</strong> flights f
<strong>WHERE</strong> f.departure='Chicago' <strong>OR</strong>
f.departure='New York'
<strong>UNION ALL</strong>
<strong>SELECT</strong>
r.departure, b.arrival, r.connects + 1 ,
r.cost + b.ticket
<strong>FROM</strong> destinations r, flights b
<strong>WHERE</strong> r.arrival=b.departure
)
<strong>SELECT</strong> departure, arrival, connects, cost
<strong>FROM</strong> destinations
<strong>WHERE</strong> r.connects&lt;=3 </pre>
</div>
<div class="section"><p>Placement of local predicates is key in recursive queries as they
can incorrectly alter the recursive results if pushed in to a recursive definition
or can cause unnecessary rows to be materialized and then rejected when a
local predicate may legitimately help limit the recursion.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzajqrecursive.htm" title="Certain applications and data are recursive by nature. Examples of such applications are a bill-of-material, reservation, trip planner or networking planning system where data in one results row has a natural relationship (call it a parent, child relationship) with data in another row or rows. Although the kinds of recursion implemented in these systems can be performed by using SQL Stored Procedures and temporary results tables, the use of a recursive query to facilitate the access of this hierarchical data can lead to a more elegant and better performing application.">Recursive query optimization</a></div>
</div>
</div>
</body>
</html>