db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r1609827 [1/2] - /db/derby/docs/trunk/src/tuning/
Date Fri, 11 Jul 2014 20:43:24 GMT
Author: chaase3
Date: Fri Jul 11 20:43:23 2014
New Revision: 1609827

URL: http://svn.apache.org/r1609827
Log:
DERBY-6379  Manuals are inconsistent in their use of the <shortdesc> element

Modified 29 Tuning Guide topics and the map file.

Patch: DERBY-6379-tun-trans.diff

Modified:
    db/derby/docs/trunk/src/tuning/ctuntransform11313.dita
    db/derby/docs/trunk/src/tuning/ctuntransform13699.dita
    db/derby/docs/trunk/src/tuning/ctuntransform13966.dita
    db/derby/docs/trunk/src/tuning/ctuntransform14044.dita
    db/derby/docs/trunk/src/tuning/ctuntransform16033.dita
    db/derby/docs/trunk/src/tuning/ctuntransform16279.dita
    db/derby/docs/trunk/src/tuning/ctuntransform21780.dita
    db/derby/docs/trunk/src/tuning/ctuntransform22576.dita
    db/derby/docs/trunk/src/tuning/ctuntransform25857.dita
    db/derby/docs/trunk/src/tuning/ctuntransform25868.dita
    db/derby/docs/trunk/src/tuning/ctuntransform35783.dita
    db/derby/docs/trunk/src/tuning/ctuntransform36368.dita
    db/derby/docs/trunk/src/tuning/ctuntransform36623.dita
    db/derby/docs/trunk/src/tuning/ctuntransform37032.dita
    db/derby/docs/trunk/src/tuning/ctuntransform47182.dita
    db/derby/docs/trunk/src/tuning/ctuntransform55045.dita
    db/derby/docs/trunk/src/tuning/ctuntransform867165.dita
    db/derby/docs/trunk/src/tuning/ctuntransform867201.dita
    db/derby/docs/trunk/src/tuning/rtuntransform139.dita
    db/derby/docs/trunk/src/tuning/rtuntransform208.dita
    db/derby/docs/trunk/src/tuning/rtuntransform345.dita
    db/derby/docs/trunk/src/tuning/rtuntransform443.dita
    db/derby/docs/trunk/src/tuning/rtuntransform472.dita
    db/derby/docs/trunk/src/tuning/rtuntransform582.dita
    db/derby/docs/trunk/src/tuning/rtuntransform590.dita
    db/derby/docs/trunk/src/tuning/rtuntransform866214.dita
    db/derby/docs/trunk/src/tuning/rtuntransform866547.dita
    db/derby/docs/trunk/src/tuning/rtuntransform866587.dita
    db/derby/docs/trunk/src/tuning/rtuntransform867602.dita
    db/derby/docs/trunk/src/tuning/tuningderby.ditamap

Modified: db/derby/docs/trunk/src/tuning/ctuntransform11313.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform11313.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform11313.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform11313.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,10 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform11313">
 <title>View transformations</title>
+<shortdesc>When <ph conref="../conrefs.dita#prod/productshortname"></ph>
+evaluates a statement that references a view, it transforms the reference to a
+view into a derived table. It might make additional transformations to improve
+performance.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>View transformations</indexterm>
@@ -26,8 +30,4 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>When <ph conref="../conrefs.dita#prod/productshortname"></ph> evaluates a statement that references a view, it transforms
-the reference to a view into a derived table. It might make additional transformations
-to improve performance.  
-</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform13699.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform13699.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform13699.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform13699.dita Fri Jul 11 20:43:23 2014
@@ -18,16 +18,15 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform13699">
 <title>Subquery processing and transformations</title>
+<shortdesc>Subqueries are notoriously expensive to evaluate. This section
+describes some of the transformations that
+<ph conref="../conrefs.dita#prod/productshortname"></ph> makes internally to
+reduce the cost of evaluating them.</shortdesc>
 <prolog><metadata>
 <keywords>
-<indexterm>Subqueries<indexterm>processing and transformations
-of</indexterm></indexterm>
+<indexterm>Subqueries<indexterm>processing and transformations of</indexterm></indexterm>
 </keywords>
 </metadata>
 </prolog>
 <conbody>
-<p>Subqueries are notoriously expensive to evaluate. This section describes
-some of the transformations that <ph conref="../conrefs.dita#prod/productshortname"></ph> makes internally to reduce the
-cost of evaluating them.  
-</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform13966.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform13966.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform13966.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform13966.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform13966">
 <title>Internal language transformations</title>
+<shortdesc>The <ph conref="../conrefs.dita#prod/productshortname"></ph> SQL
+parser sometimes transforms SQL statements internally for performance reasons.
+This section describes those transformations.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Language transformations for performance</indexterm>
@@ -33,46 +36,54 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>The <ph conref="../conrefs.dita#prod/productshortname"></ph> SQL parser sometimes transforms SQL statements
-internally for performance reasons. This appendix describes those transformations.
-Understanding the internal language transformations can help you analyze and
+<p>Understanding the internal language transformations can help you analyze and
 tune performance. Understanding the internal language transformations is not
 necessary for the general user.</p>
 <p>This chapter uses some specialized terms. Here are some
 definitions:</p>
-<dl id="i827520">
+<dl>
 <dlentry><dt id="rtuntransform41494">base table</dt>
-<dd>A real table in a FROM list. In queries that involve "virtual"
-tables such as views and derived tables, base tables are the underlying tables
-to which virtual tables correspond.</dd></dlentry>
+<dd>A real table in a FROM list. In queries that involve "virtual" tables such
+as views and derived tables, base tables are the underlying tables to which
+virtual tables correspond.</dd></dlentry>
 <dlentry><dt>derived table</dt>
 <dd>A virtual table, such as a subquery given a correlation name or a view.
-For example:<i> SELECT derivedtable.c1 FROM (VALUES ('a','b'))
-AS derivedtable(c1,c2)</i>.</dd></dlentry>
+For example:
+<codeblock><b>SELECT derivedtable.c1 FROM (VALUES ('a','b'))
+AS derivedtable(c1,c2)</b></codeblock></dd></dlentry>
 <dlentry><dt id="rtuntransform24389">equality predicate</dt>
-<dd>A <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform25022">predicate</xref> in which one value is
-compared to another value using the = operator.</dd></dlentry>
+<dd>A
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform25022">predicate</xref>
+in which one value is compared to another value using the <codeph>=</codeph>
+operator.</dd></dlentry>
 <dlentry><dt id="rtuntransform36163">equijoin predicate</dt>
 <dd>A predicate in which one column is compared to a column in another table
-using the = operator.</dd></dlentry>
+using the <codeph>=</codeph> operator.</dd></dlentry>
 <dlentry><dt id="rtuntransform19435">optimizable</dt>
-<dd>A predicate is <i>optimizable</i> if it provides a
-starting or stopping point and allows use of an index. Optimizable predicates
-use only <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple column reference</xref>s and =, &lt;, &gt;, +, &gt;=,
-and IS NULL operators. For complete details, see <xref href="ctunoptimz39106.dita#ctunoptimz39106"/>. A synonym for <i>optimizable</i> is  <i>indexable</i>.</dd></dlentry>
+<dd>A predicate is <i>optimizable</i> if it provides a starting or stopping
+point and allows use of an index. Optimizable predicates use only
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple column reference</xref>s
+and <codeph>=</codeph>, <codeph>&lt;</codeph>, <codeph>&gt;</codeph>,
+<codeph>+</codeph>, <codeph>&gt;=</codeph>, and IS NULL operators. For complete
+details, see <xref href="ctunoptimz39106.dita"/>. A synonym for
+<i>optimizable</i> is <i>indexable</i>.</dd></dlentry>
 <dlentry><dt id="rtuntransform25022">predicate</dt>
 <dd>A WHERE clause contains boolean expressions that can be linked together
-by AND or OR clauses. Each part is called a <i>predicate</i>.
-For example: <i>WHERE c1 =2 AND c2 = 5</i> contains two predicates.</dd></dlentry>
+by AND or OR clauses. Each part is called a <i>predicate</i>. For example, the
+following clause contains two predicates:
+<codeblock><b>WHERE c1 =2 AND c2 = 5</b></codeblock></dd></dlentry>
 <dlentry><dt id="rtuntransform26698">sargable</dt>
-<dd><i>Sargable</i> predicates are a superset of optimizable
-predicates; not all sargable predicates are optimizable, because sargable
-predicates also include the &lt;&gt; operator. (<i>Sarg</i> stands
-for "search argument.") Predicates that are sargable but not optimizable
-nevertheless improve performance and allow the optimizer to use more accurate
-costing information.   
-<p>In addition, sargable predicates can be <i>pushed down </i>(see <xref href="ctuntransform36623.dita#ctuntransform36623"/>).</p></dd></dlentry>
+<dd><i>Sargable</i> predicates are a superset of optimizable predicates; not all
+sargable predicates are optimizable, because sargable predicates also include
+the <codeph>&lt;&gt;</codeph> operator. (<i>Sarg</i> stands for "search
+argument.") Predicates that are sargable but not optimizable nevertheless
+improve performance and allow the optimizer to use more accurate costing
+information.
+<p>In addition, sargable predicates can be <i>pushed down </i>(see
+<xref href="ctuntransform36623.dita"/>).</p></dd></dlentry>
 <dlentry><dt id="rtuntransform13785">simple column reference</dt>
-<dd>A reference to a column that is not part of an expression. For example, <i>c1</i> is a simple column reference, but <i>c1+1,</i> <i>max(c1)</i>, and <i>lower(c1)</i> are not.</dd></dlentry>
+<dd>A reference to a column that is not part of an expression. For example,
+<codeph>c1</codeph> is a simple column reference, but <codeph>c1+1</codeph>,
+<codeph>max(c1)</codeph>, and <codeph>lower(c1)</codeph> are not.</dd></dlentry>
 </dl>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform14044.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform14044.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform14044.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform14044.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform14044">
 <title>Combining ORDER BY and UNION</title>
+<shortdesc>Without a transformation, a statement that contains both ORDER BY and
+UNION would require two separate sorting steps-one to satisfy ORDER BY and one
+to satisfy UNION.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>UNION<indexterm>avoiding ordering during</indexterm></indexterm>
@@ -25,31 +28,31 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>Without a transformation, a statement that contains both ORDER BY and UNION
-would require two separate sorting steps-one to satisfy ORDER BY and
-one to satisfy UNION (Currently <ph conref="../conrefs.dita#prod/productshortname"></ph> uses sorting to eliminate duplicates
-from a UNION.  You can use UNION ALL to avoid sorting, but UNION ALL will return duplicates.  So you only use UNION ALL to avoid sorting if you know that there are no duplicate rows in the tables).</p>
-<p>In some situations, <ph conref="../conrefs.dita#prod/productshortname"></ph> can transform the statement internally
-into one that contains only one of these keywords (the ORDER BY is thrown
-out). The requirements are:  
+<p>Currently <ph conref="../conrefs.dita#prod/productshortname"></ph> uses
+sorting to eliminate duplicates from a UNION. You can use UNION ALL to avoid
+sorting, but UNION ALL will return duplicates. So you only use UNION ALL to
+avoid sorting if you know that there are no duplicate rows in the tables.</p>
+<p>In some situations, <ph conref="../conrefs.dita#prod/productshortname"></ph>
+can transform the statement internally into one that contains only one of these
+keywords (the ORDER BY is thrown out). The requirements are as follows:</p>
 <ul>
 <li>The columns in the ORDER BY list must be a subset of the columns in the
-select list of the left side of the union. </li>
-<li>All the columns in the ORDER BY list must be sorted in ascending order
+select list of the left side of the union.</li>
+<li>All the columns in the ORDER BY list must be sorted in ascending order,
 and they must be an in-order prefix of the columns in the target list of the
-left side of the UNION. </li>
-</ul></p>
-<p><ph conref="../conrefs.dita#prod/productshortname"></ph> will be able to transform the following statements:   
+left side of the UNION.</li>
+</ul>
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> will be able to
+transform the following statements:</p>
 <codeblock><b>SELECT miles, meal
 FROM Flights
 UNION VALUES (1000, 'D')
-ORDER BY 1
-</b></codeblock></p>
-<p><ph conref="../conrefs.dita#prod/productshortname"></ph> cannot avoid two sorting nodes in the following statement,
-because of the order of the columns in the ORDER BY clause:  
+ORDER BY 1</b></codeblock>
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> cannot avoid two
+sorting nodes in the following statement, because of the order of the columns in
+the ORDER BY clause:</p>
 <codeblock><b>SELECT flight_id, segment_number FROM Flights
 UNION
 SELECT flight_id, segment_number FROM FlightAvailability
-ORDER BY segment_number , flight_id
-</b></codeblock></p>
+ORDER BY segment_number , flight_id</b></codeblock>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform16033.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform16033.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform16033.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform16033.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform16033">
 <title>Sort avoidance</title>
+<shortdesc>Sorting is an expensive process.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> tries to eliminate
+unnecessary sorting steps where possible.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Sort avoidance</indexterm>
@@ -26,7 +29,4 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>Sorting is an expensive process. <ph conref="../conrefs.dita#prod/productshortname"></ph> tries to eliminate unnecessary
-sorting steps where possible.  
-</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform16279.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform16279.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform16279.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform16279.dita Fri Jul 11 20:43:23 2014
@@ -19,43 +19,47 @@ limitations under the License.
 -->
 <concept id="ctuntransform16279" xml:lang="en-us">
 <title>DISTINCT elimination based on a uniqueness condition</title>
+<shortdesc>A DISTINCT (and the corresponding sort) can be eliminated from a
+query if a uniqueness condition exists that ensures that no duplicate values
+will be returned.</shortdesc>
 <prolog><metadata>
 <keywords><indexterm>DISTINCT<indexterm>eliminated for uniqueness condition</indexterm></indexterm>
 </keywords>
 </metadata></prolog>
 <conbody>
-<p>A DISTINCT (and the corresponding sort) can be eliminated from a query
-if a uniqueness condition exists that ensures that no duplicate values will
-be returned. If no duplicate values are returned, the DISTINCT node is superfluous,
-and <ph conref="../conrefs.dita#prod/productshortname"></ph> transforms the
+<p>If no duplicate values are returned, the DISTINCT node is superfluous, and
+<ph conref="../conrefs.dita#prod/productshortname"></ph> transforms the
 statement internally into one without the DISTINCT keyword.</p>
-<p>The requirements are:   <ul>
-<li>No GROUP BY list. </li>
-<li>SELECT list contains at least one <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref>. </li>
-<li>Every <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref> is from the same table. </li>
-<li>Every table in the FROM list is a <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base
-table</xref>. </li>
-<li id="i828502"><i id="rtuntransform29680">Primary table</i>   <p>There is
-at least one unique index on one table in the FROM list for which <i>all</i> the
-columns appear in one of the following:</p>  <ul>
-<li><xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform24389">equality
-predicate</xref>s with expressions that do not include any column references</li>
-<li><xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref>s in the SELECT list</li>
+<p>The requirements are as follows:</p>
+<ul>
+<li>No GROUP BY list.</li>
+<li>SELECT list contains at least one
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
+column reference</xref>.</li>
+<li>Every simple column reference is from the same table.</li>
+<li>Every table in the FROM list is a
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base
+table</xref>.</li>
+<li id="rtuntransform29680"><i>Primary table</i>
+<p>There is at least one unique index on one table in the FROM list for which
+<i>all</i> the columns appear in one of the following:</p>
+<ul>
+<li><xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform24389">Equality
+predicate</xref>s with expressions that do not include any column
+references</li>
+<li>Simple column references in the SELECT list</li>
 </ul></li>
-<li id="i828529"><i id="rtuntransform16930">Secondary table(s)</i>   <p>All
-the other tables in the FROM list also have at least one unique index for
-which all the columns appear in one of the following:</p>  <ul>
-<li><xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform24389">equality
-predicate</xref>s with expressions that do not include columns from the same
-table</li>
-<li><xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref>s in the SELECT list</li>
+<li id="rtuntransform16930"><i>Secondary table(s)</i>
+<p>All the other tables in the FROM list also have at least one unique index for
+which all the columns appear in one of the following:</p>
+<ul>
+<li>Equality predicates with expressions that do not include columns from the
+same table</li>
+<li>Simple column references in the SELECT list</li>
 </ul></li>
-</ul></p>
-<p>For example:   <codeblock><b>CREATE TABLE tab1 (c1 INT NOT NULL, 
+</ul>
+<p>For example:</p>
+<codeblock><b>CREATE TABLE tab1 (c1 INT NOT NULL, 
     c2 INT NOT NULL, 
     c3 INT NOT NULL, 
     c4 CHAR(2), 
@@ -72,28 +76,26 @@ INSERT INTO tab2 VALUES (1, 2), 
     (1, 3), 
     (2, 2), 
     (2, 3)
-<b>-- all the columns in the index on the only table (tab1) appear
--- in the way required for the <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform29680">Primary table</xref> (simple column references)</b
->
+-- all the columns in the index on the only table (tab1) appear
+-- in the way required for the <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform29680">Primary table</xref> (simple column references)
 SELECT DISTINCT c1, c2, c3, c4
 FROM tab1
-<b>-- all the columns in the index on the only table (tab1) appear
--- in the way required for the <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform29680">Primary table</xref> (equality predicates) </b
->
+-- all the columns in the index on the only table (tab1) appear
+-- in the way required for the <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform29680">Primary table</xref> (equality predicates)
 SELECT DISTINCT c3, c4
 FROM tab1
 WHERE c1 = 1
 AND c2 = 2
 AND c4 = 'WA'
-<b>-- all the columns in the index on tab1 appear
+-- all the columns in the index on tab1 appear
 -- in the way required for the <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform29680">Primary table</xref>,
 -- and all the columns in the
 -- other tables appear in the way required
--- for a <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform16930">Secondary table</xref></b>
+-- for a <xref href="ctuntransform16279.dita#ctuntransform16279/rtuntransform16930">Secondary table</xref>
 SELECT DISTINCT tab1.c1, tab1.c3, tab1.c4
 FROM tab1, tab2
 WHERE tab1.c2 = 2
 AND tab2.c2 = tab1.c2
-AND tab2.c1 = tab1.c1</b></codeblock></p>
+AND tab2.c1 = tab1.c1</b></codeblock>
 </conbody>
 </concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform21780.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform21780.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform21780.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform21780.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,12 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform21780">
 <title>Combining ORDER BY and DISTINCT</title>
+<shortdesc>Without a transformation, a statement that contains both DISTINCT
+and ORDER BY would require two separate sorting steps-one to satisfy DISTINCT
+and one to satisfy ORDER BY. (Currently,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> uses sorting to
+evaluate DISTINCT. There are, in theory, other ways to accomplish
+this.)</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>DISTINCT<indexterm>combined with ORDER BY</indexterm></indexterm>
@@ -25,24 +31,22 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>Without a transformation, a statement that contains both DISTINCT and ORDER
-BY would require two separate sorting steps-one to satisfy DISTINCT
-and one to satisfy ORDER BY. (Currently, <ph conref="../conrefs.dita#prod/productshortname"></ph> uses sorting to evaluate
-DISTINCT. There are, in theory, other ways to accomplish this.) In some situations, <ph conref="../conrefs.dita#prod/productshortname"></ph> can
-transform the statement internally into one that contains only one of these
-keywords. The requirements are:  
+<p>In some situations, <ph conref="../conrefs.dita#prod/productshortname"></ph>
+can transform the statement internally into one that contains only one of these
+keywords. The requirements are as follows:</p>
 <ul>
 <li>The columns in the ORDER BY list must be a subset of the columns in the
 SELECT list.</li>
 <li>All the columns in the ORDER BY list are sorted in ascending order.</li>
-</ul></p>
+</ul>
 <p>A unique index is not required.</p>
-<p>For example:  
+<p>For example,</p>
 <codeblock><b>SELECT DISTINCT miles, meal
 FROM Flights
-ORDER BY meal</b></codeblock></p>
-<p>is transformed into  
+ORDER BY meal</b></codeblock>
+<p>is transformed into</p>
 <codeblock><b>SELECT DISTINCT miles, meal
-FROM Flights</b></codeblock>Note that these are not equivalent functions; this
-is simply an internal <ph conref="../conrefs.dita#prod/productshortname"></ph> transformation.</p>
+FROM Flights</b></codeblock>
+<p>Note that these are not equivalent functions; this is simply an internal
+<ph conref="../conrefs.dita#prod/productshortname"></ph> transformation.</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform22576.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform22576.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform22576.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform22576.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,10 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform22576">
 <title>View flattening</title>
+<shortdesc>When evaluating a statement that references a view,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> internally transforms a
+view into a derived table. This derived table might also be a candidate for
+<i>flattening</i> into the outer query block.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>View flattening</indexterm>
@@ -25,34 +29,32 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>When evaluating a statement that references a view, <ph conref="../conrefs.dita#prod/productshortname"></ph> internally
-transforms a view into a derived table. This derived table might also be a
-candidate for <i>flattening</i> into the outer query block.</p>
-<p>A view or derived table can be flattened into the outer query block if
-all of the following conditions are met:   
+<p>A view or derived table can be flattened into the outer query block if all of
+the following conditions are met:</p>
 <ul>
-<li>The select list is composed entirely of <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple column reference</xref>s and constants.</li>
-<li>There is no GROUP BY clause in the view. </li>
-<li>There is no DISTINCT in the view. </li>
+<li>The select list is composed entirely of
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple column reference</xref>s
+and constants.</li>
+<li>There is no GROUP BY clause in the view.</li>
+<li>There is no DISTINCT in the view.</li>
 <li>There is no ORDER BY, result offset, or fetch first clause in the view.</li>
-</ul></p>
-<p>For example, given view <i>v1(a,b):</i>  
+</ul>
+<p>For example, given view <codeph>v1(a,b)</codeph>:</p>
 <codeblock><b>SELECT Cities.city_name, Countries.country_iso_code
 FROM Cities, Countries
-WHERE Cities.country_iso_code = Countries.country_iso_code</b></codeblock></p>
-<p>and a SELECT that references it:  
+WHERE Cities.country_iso_code = Countries.country_iso_code</b></codeblock>
+<p>and a SELECT that references it:</p>
 <codeblock><b>SELECT a, b
-FROM v1 WHERE a = 'Melbourne'</b></codeblock></p>
-<p>after the view is transformed into a derived table, the internal query
-is  
+FROM v1 WHERE a = 'Melbourne'</b></codeblock>
+<p>After the view is transformed into a derived table, the internal query is</p>
 <codeblock><b>SELECT a, b
 FROM (select Cities.city_name, Countries.country_iso_code
 FROM Cities, Countries
 WHERE Cities.country_iso_code = Countries.country_iso_code) v1(a, b)
-WHERE a = 'Melbourne'</b></codeblock></p>
-<p>After view flattening it becomes  
+WHERE a = 'Melbourne'</b></codeblock>
+<p>After view flattening it becomes</p>
 <codeblock><b>SELECT Cities.city_name, Countries.country_iso_code
 FROM Cities, Countries
 WHERE Cities.country_iso_code = Countries.country_iso_code
-AND Cities.city_name = 'Melbourne'</b></codeblock></p>
+AND Cities.city_name = 'Melbourne'</b></codeblock>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform25857.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform25857.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform25857.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform25857.dita Fri Jul 11 20:43:23 2014
@@ -20,45 +20,59 @@ limitations under the License.
 -->
 <concept id="ctuntransform25857" xml:lang="en-us">
 <title>Materialization</title>
+<shortdesc><term>Materialization</term> means that a subquery is evaluated only
+once. Several types of subqueries can be materialized.</shortdesc>
 <prolog><metadata>
 <keywords><indexterm>subqueries<indexterm>materialization</indexterm></indexterm>
 <indexterm><indexterm>materialization</indexterm>subqueries</indexterm></keywords>
 </metadata></prolog>
 <conbody>
-<p><term>Materialization</term> means that a subquery is evaluated
-only once. Several types of subqueries can be materialized.</p>
-<section><title>Expression subqueries that are not correlated</title><p>A
-subquery can be materialized if it is a noncorrelated expression subquery.
-A correlated subquery is one that references columns in the outer query, and
-so has to be evaluated for each row in the outer query.</p><p>For example:
-   <codeblock><b>SELECT * FROM Staff WHERE id = (SELECT MAX(manager) FROM Org)</b></codeblock></p><p>In
-this statement, the subquery needs to be evaluated only once.</p><p>This type
-of subquery must return only one row. If evaluating the subquery causes a
-cardinality violation (if it returns more than one row), an exception is thrown
-when the subquery is run. </p><p>Subquery materialization is detected before
-optimization, which allows the <ph conref="../conrefs.dita#prod/productshortname"></ph> optimizer
-to see a materialized subquery as an unknown constant value. The comparison
-is therefore optimizable. </p><p>The original statement is transformed into
-the following two statements:    <codeblock><b><i>constant</i></b> = SELECT MAX(manager) FROM Org
+<section><title>Expression subqueries that are not correlated</title>
+<p>A subquery can be materialized if it is a noncorrelated expression subquery.
+A correlated subquery is one that references columns in the outer query, and so
+has to be evaluated for each row in the outer query.</p>
+<p>For example:</p>
+<codeblock><b>SELECT * FROM Staff
+WHERE id = (SELECT MAX(manager) FROM Org)</b></codeblock>
+<p>In this statement, the subquery needs to be evaluated only once.</p>
+<p>This type of subquery must return only one row. If evaluating the subquery
+causes a cardinality violation (if it returns more than one row), an exception
+is thrown when the subquery is run.</p>
+<p>Subquery materialization is detected before optimization, which allows the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> optimizer to see a
+materialized subquery as an unknown constant value. The comparison is therefore
+optimizable.</p>
+<p>The original statement is transformed into the following two statements:</p>
+<codeblock><b><i>constant</i> = SELECT MAX(manager) FROM Org
 SELECT * FROM Staff
-WHERE id = <b><i>constant</i></b></codeblock></p><p>The second statement is
-optimizable.</p></section>
-<section><title>Subqueries that cannot be flattened</title><p>Materialization
-of a subquery can also occur when the subquery is nonflattenable and there
-is an equijoin between the subquery and another FROM table in the query. </p><p>For
-example:   <codeblock>SELECT i, a  FROM t1, 
+WHERE id = <i>constant</i></b></codeblock>
+<p>The second statement is optimizable.</p>
+</section>
+<section><title>Subqueries that cannot be flattened</title>
+<p>Materialization of a subquery can also occur when the subquery is
+nonflattenable and there is an equijoin between the subquery and another FROM
+table in the query.</p>
+<p>For example:</p>
+<codeblock><b>SELECT i, a FROM t1, 
    (SELECT DISTINCT a FROM T2) x1  
-WHERE t1.i = x1.a AND t1.i in (1, 3, 5, 7) </codeblock>In this example, the
-subquery x1 is noncorrelated because it does not reference any of the columns
-from the outer query. The subquery is nonflattenable because of the DISTINCT
-keyword. <ph conref="../conrefs.dita#prod/productshortname"></ph> does not
-flatten DISTINCT subqueries. This subquery is eligible for materialization.
-Since there is an equijoin predicate between the subquery x1 and the table
-t1 (namely, t1.i = x1.a), the <ph conref="../conrefs.dita#prod/productshortname"></ph> optimizer
-will consider performing a hash join between t1 and x1 (with x1 as the inner
-operand). If that approach yields the best cost, <ph conref="../conrefs.dita#prod/productshortname"></ph> materializes
-the subquery x1 to perform the hash join. The subquery is evaluated only a
-single time and the results are stored in an in-memory hash table. <ph conref="../conrefs.dita#prod/productshortname"></ph> then
-executes the join using the in-memory result set for x1.</p></section>
+WHERE t1.i = x1.a AND t1.i in (1, 3, 5, 7)</b></codeblock>
+<p>In this example, the subquery <codeph>x1</codeph> is noncorrelated because it
+does not reference any of the columns from the outer query. The subquery is
+nonflattenable because of the DISTINCT keyword.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> does not flatten
+DISTINCT subqueries. This subquery is eligible for materialization. Since there
+is an
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform36163">equijoin
+predicate</xref> between the subquery <codeph>x1</codeph> and the table
+<codeph>t1</codeph> (namely, <codeph>t1.i = x1.a</codeph>), the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> optimizer will consider
+performing a hash join between <codeph>t1</codeph> and <codeph>x1</codeph> (with
+<codeph>x1</codeph> as the inner operand). If that approach yields the best
+cost, <ph conref="../conrefs.dita#prod/productshortname"></ph> materializes the
+subquery <codeph>x1</codeph> to perform the hash join. The subquery is evaluated
+only a single time, and the results are stored in an in-memory hash table.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> then executes the join
+using the in-memory result set for <codeph>x1</codeph>.</p>
+</section>
 </conbody>
 </concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform25868.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform25868.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform25868.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform25868.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,8 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform25868">
 <title>Flattening a subquery into an EXISTS join</title>
+<shortdesc>An EXISTS join is a join in which the right side of the join needs to
+be probed only once for each outer row.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Subqueries<indexterm>flattening of to an EXISTS join</indexterm></indexterm>
@@ -26,47 +28,56 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>An EXISTS join is a join in which the right side of the join needs to be
-probed only once for each outer row. Using such a definition, an EXISTS join
-does not literally use the EXISTS keyword. <ph conref="../conrefs.dita#prod/productshortname"></ph> treats a statement
-as an EXISTS join when there will be at most one matching row from the right
-side of the join for a given row in the outer table.</p>
-<p>A subquery that cannot be flattened into a normal join because of a uniqueness
-condition can be flattened into an EXISTS join if it meets all the requirements
-(see below). Recall the first example from the previous section (<xref href="ctuntransform36368.dita#ctuntransform36368"/>):</p>
-<codeblock><b>SELECT c1 FROM t1 WHERE c1 IN (SELECT c1 FROM t2)</b></codeblock>
+<p>Using such a definition, an EXISTS join does not literally use the EXISTS
+keyword. <ph conref="../conrefs.dita#prod/productshortname"></ph> treats a
+statement as an EXISTS join when there will be at most one matching row from the
+right side of the join for a given row in the outer table.</p>
+<p>A subquery that cannot be flattened into a normal join because of a
+uniqueness condition can be flattened into an EXISTS join if it meets all the
+requirements (see below). Recall the first example from
+<xref href="ctuntransform36368.dita"/>:</p>
+<codeblock><b>SELECT c1 FROM t1 
+WHERE c1 IN (SELECT c1 FROM t2)</b></codeblock>
 <p>This query could not be flattened into a normal join because such a join
-would return the wrong results. However, this query can be flattened into
-a join recognized internally by the <ph conref="../conrefs.dita#prod/productshortname"></ph> system as an EXISTS join.
-When processing an EXISTS join, <ph conref="../conrefs.dita#prod/productshortname"></ph> knows to stop processing the right
-side of the join after a single row is returned. The transformed statement
-would look something like this:  
+would return the wrong results. However, this query can be flattened into a join
+recognized internally by the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> system as an EXISTS
+join. When processing an EXISTS join,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> knows to stop
+processing the right side of the join after a single row is returned. The
+transformed statement would look something like this:</p>
 <codeblock><b>SELECT c1 FROM t1, t2
 WHERE t1.c1 = t2.c1
-EXISTS JOIN INTERNAL SYNTAX</b></codeblock></p>
-<p>Requirements for flattening into an EXISTS join:   
+EXISTS JOIN INTERNAL SYNTAX</b></codeblock>
+<p>Requirements for flattening into an EXISTS join are as follows:</p> 
 <ul>
-<li>The subquery is not under an OR. </li>
-<li>The subquery type is EXISTS, IN, or ANY. </li>
-<li>The subquery is not in the SELECT list of the outer query block. </li>
-<li>There are no aggregates in the SELECT list of the subquery. </li>
-<li>The subquery does not have a GROUP BY clause. </li>
+<li>The subquery is not under an OR.</li>
+<li>The subquery type is EXISTS, IN, or ANY.</li>
+<li>The subquery is not in the SELECT list of the outer query block.</li>
+<li>There are no aggregates in the SELECT list of the subquery.</li>
+<li>The subquery does not have a GROUP BY clause.</li>
 <li>The subquery does not have an ORDER BY, result offset, or fetch first
 clause.</li>
-<li>The subquery has a single entry in its FROM list that is a <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base table</xref>. </li>
+<li>The subquery has a single entry in its FROM list that is a
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base
+table</xref>. </li>
 <li>None of the predicates in the subquery, including the additional one formed
 between the left side of the subquery operator and the column in the subquery's
 SELECT list (for IN or ANY subqueries), include any subqueries, method calls,
 or field accesses. </li>
-</ul></p>
+</ul>
 <p>When a subquery is flattened into an EXISTS join, the table from the subquery
-is made join-order-dependent on all the tables with which it is correlated.
-This means that a table must appear inner to all the tables on which it is
-join-order-dependent. (In subsequent releases this restrictions can be relaxed.)
-For example:   
+is made join-order-dependent on all the tables with which it is correlated. This
+means that a table must appear inner to all the tables on which it is
+join-order-dependent. For example,</p>
 <codeblock><b>SELECT t1.* FROM t1, t2
-WHERE EXISTS (SELECT * FROM t3 WHERE t1.c1 = t3.c1)</b></codeblock></p>
-<p>gets flattened into  
-<codeblock><b>SELECT t1.* FROM t1, t2, t3 WHERE t1.c1 = t3.c1</b></codeblock></p>
-<p>where <i>t3</i> is join order dependent on <i>t1</i>. This means that the possible join orders are (<i>t1</i>, <i>t2</i>, <i>t3</i>), (<i>t1</i>, <i>t3</i>, <i>t2</i>), and (<i>t2</i>, <i>t1</i>, <i>t3</i>).</p>
+WHERE EXISTS (SELECT * FROM t3 WHERE t1.c1 = t3.c1)</b></codeblock>
+<p>gets flattened into</p>
+<codeblock><b>SELECT t1.* FROM t1, t2, t3 
+WHERE t1.c1 = t3.c1</b></codeblock>
+<p>where <codeph>t3</codeph> is join order dependent on <codeph>t1</codeph>.
+This means that the possible join orders are (<codeph>t1</codeph>,
+<codeph>t2</codeph>, <codeph>t3</codeph>), (<codeph>t1</codeph>,
+<codeph>t3</codeph>, <codeph>t2</codeph>), and (<codeph>t2</codeph>,
+<codeph>t1</codeph>, <codeph>t3</codeph>).</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform35783.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform35783.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform35783.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform35783.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform35783">
 <title>Predicate transformations</title>
+<shortdesc>WHERE clauses with predicates joined by OR are usually not
+optimizable. WHERE clauses with predicates joined by AND are optimizable if
+<i>at least one</i> of the predicates is optimizable.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Internal transformation of statements<indexterm>predicates</indexterm></indexterm>
@@ -25,23 +28,22 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>WHERE clauses with <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform25022">predicate</xref>s joined
-by OR are usually not optimizable. WHERE clauses with predicates joined by
-AND are optimizable if <i>at least one</i> of the predicates
-is optimizable. For example:  
+<p>For example:</p>
 <codeblock><b>SELECT * FROM Flights
 WHERE flight_id = 'AA1111'
-AND segment_number &lt;&gt; 2</b></codeblock></p>
-<p>In this example, the first predicate is optimizable; the second predicate
-is not. Therefore, the statement is optimizable.  
-<note>In a few
-cases, a WHERE clause with predicates joined by OR can be transformed into
-an optimizable statement. See <xref href="rtuntransform590.dita#rtuntransform590"/>.</note></p>
-<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can transform some predicates internally so that at least one
-of the predicates is optimizable and thus the statement is optimizable. This
-section describes the predicate transformations that <ph conref="../conrefs.dita#prod/productshortname"></ph> performs
-to make predicates optimizable.</p>
-<p>A predicate that uses the following comparison operators can sometimes
-be transformed internally into optimizable predicates. 
-</p>
+AND segment_number &lt;&gt; 2</b></codeblock>
+<p>In this example, the first
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform25022">predicate</xref>
+is optimizable; the second predicate is not. Therefore, the statement is
+optimizable.</p>
+<p><note>In a few cases, a WHERE clause with predicates joined by OR can be
+transformed into an optimizable statement. See
+<xref href="rtuntransform590.dita"/>.</note></p>
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can transform some
+predicates internally so that at least one of the predicates is optimizable and
+thus the statement is optimizable. This section describes the predicate
+transformations that <ph conref="../conrefs.dita#prod/productshortname"></ph>
+performs to make predicates optimizable.</p>
+<p>A predicate that uses the following comparison operators can sometimes be
+transformed internally into optimizable predicates.</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform36368.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform36368.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform36368.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform36368.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,11 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform36368">
 <title>Flattening a subquery into a normal join</title>
+<shortdesc>Subqueries are allowed to return more than one row when used with IN,
+EXISTS, and ANY. However, for each row returned in the outer row,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> evaluates the subquery
+until it returns one row; it does not evaluate the subquery for all rows
+returned.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Subqueries<indexterm>flattening of</indexterm></indexterm>
@@ -25,11 +30,7 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>Subqueries are allowed to return more than one row when used with IN, EXISTS,
-and ANY. However, for each row returned in the outer row, <ph conref="../conrefs.dita#prod/productshortname"></ph> evaluates
-the subquery until it returns one row; it does not evaluate the subquery for
-all rows returned.</p>
-<p>For example, given two tables, <i>t1</i> and <i>t2</i>:</p>
+<p>For example, given two tables, <codeph>t1</codeph> and <codeph>t2</codeph>:</p>
 <codeblock><b>c1</b>
 --
  1
@@ -42,85 +43,90 @@ all rows returned.</p>
  2
  1
 </codeblock>
-<p>and the following query:
-<codeblock><b>SELECT c1 FROM t1 WHERE c1 IN (SELECT c1 FROM t2)</b></codeblock></p>
-<p>the results would be  
+<p>and the following query:</p>
+<codeblock><b>SELECT c1 FROM t1 WHERE c1 IN (SELECT c1 FROM t2)</b></codeblock>
+<p>the results would be</p>
 <codeblock>1
-2</codeblock></p>
-<p>Simply selecting <i>t1.c1</i> when simply joining those
-tables has different results:  
+2</codeblock>
+<p>Simply selecting <codeph>t1.c1</codeph> when simply joining those tables has
+different results:</p>
 <codeblock><b>SELECT t1.c1 FROM t1, t2 WHERE t1.c1 = t2.c1
    1
    2
-   2</b></codeblock></p>
-<p>Statements that include such subqueries can be flattened into joins only
-if the subquery does not introduce any duplicates into the result set (in
-our example, the subquery introduced a duplicate and so cannot simply be flattened
-into a join). If this requirement and other requirements (listed below) are
-met, however, the statement is flattened such that the tables in the subquery's
-FROM list are treated as if they were inner to the tables in the outer FROM
-list.</p>
-<p>For example, the query could have been flattened into a join if <i>c1</i> in <i>t2</i> had a unique index on it. It would not
-have introduced any duplicate values into the result set.</p>
-<p>The requirements for flattening into a normal join are:   
+   2</b></codeblock>
+<p>Statements that include such subqueries can be flattened into joins only if
+the subquery does not introduce any duplicates into the result set (in our
+example, the subquery introduced a duplicate and so cannot simply be flattened
+into a join). If this requirement and other requirements (listed below) are met,
+however, the statement is flattened such that the tables in the subquery's FROM
+list are treated as if they were inner to the tables in the outer FROM list.</p>
+<p>For example, the query could have been flattened into a join if
+<codeph>c1</codeph> in <codeph>t2</codeph> had a unique index on it. It would
+not have introduced any duplicate values into the result set.</p>
+<p>The requirements for flattening into a normal join are as follows:</p>
 <ul>
-<li>The subquery is not under an OR. </li>
-<li>The subquery type is EXISTS, IN, or ANY, or it is an expression subquery
-on the right side of a comparison operator. </li>
-<li>The subquery is not in the SELECT list of the outer query block. </li>
-<li>There are no aggregates in the SELECT list of the subquery. </li>
-<li>The subquery does not have a GROUP BY clause. </li>
+<li>The subquery is not under an OR.</li>
+<li>The subquery type is EXISTS, IN, or ANY, or it is an expression subquery on
+the right side of a comparison operator.</li>
+<li>The subquery is not in the SELECT list of the outer query block.</li>
+<li>There are no aggregates in the SELECT list of the subquery.</li>
+<li>The subquery does not have a GROUP BY clause.</li>
 <li>The subquery does not have an ORDER BY, result offset, or fetch first
 clause.</li>
 <li>There is a uniqueness condition that ensures that the subquery does not
-introduce any duplicates if it is flattened into the outer query block. </li>
-<li>Each table in the subquery's FROM list (after any view, derived table,
-or subquery flattening) must be a <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base table</xref>.</li>
-<li>If there is a WHERE clause in the subquery, there is at least one table
-in the subquery whose columns are in <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform24389">equality predicate</xref>s
-with expressions that do not include any column references from the subquery
-block. These columns must be a superset of the key columns for any unique
-index on the table. For all other tables in the subquery, the columns in equality
-predicates with expressions that do not include columns from the same table
-are a superset of the unique columns for any unique index on the table.</li>
-</ul></p>
+introduce any duplicates if it is flattened into the outer query block.</li>
+<li>Each table in the subquery's FROM list (after any view, derived table, or
+subquery flattening) must be a
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base
+table</xref>.</li>
+<li>If there is a WHERE clause in the subquery, there is at least one table in
+the subquery whose columns are in
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform24389">equality
+predicate</xref>s with expressions that do not include any column references
+from the subquery block. These columns must be a superset of the key columns for
+any unique index on the table. For all other tables in the subquery, the columns
+in equality predicates with expressions that do not include columns from the
+same table are a superset of the unique columns for any unique index on the
+table.</li>
+</ul>
 <p>Flattening into a normal join gives the optimizer more options for choosing
-the best query plan. For example, if the following statement:   
+the best query plan. For example, if the following statement:</p>
 <codeblock><b>SELECT huge.* FROM huge
-WHERE c1 IN (SELECT c1 FROM tiny)</b></codeblock></p>
-<p>can be flattened into  
-<codeblock><b>SELECT huge.* FROM huge, tiny WHERE huge.c1 = tiny.c1</b></codeblock></p>
-<p>the optimizer can choose a query plan that will scan <i>tiny</i> and do a few probes into the huge table instead of scanning the
-huge table and doing a large number of probes into the tiny table. </p>
-<p>Here is an expansion of the example used earlier in this section. Given
- 
+WHERE c1 IN (SELECT c1 FROM tiny)</b></codeblock>
+<p>can be flattened into</p>
+<codeblock><b>SELECT huge.* FROM huge, tiny
+WHERE huge.c1 = tiny.c1</b></codeblock>
+<p>the optimizer can choose a query plan that will scan <codeph>tiny</codeph>
+and do a few probes into the huge table instead of scanning the huge table and
+doing a large number of probes into the tiny table.</p>
+<p>Here is an expansion of the example used earlier in this section. Given</p>
 <codeblock><b>CREATE TABLE t1 (c1 INT)
 CREATE TABLE t2 (c1 INT NOT NULL PRIMARY KEY)
 CREATE TABLE t3 (c1 INT NOT NULL PRIMARY KEY)
 INSERT INTO t1 VALUES (1), (2), (3)
 INSERT INTO t2 VALUES (1), (2), (3)
-INSERT INTO t3 VALUES (2), (3), (4)</b></codeblock></p>
-<p>this query  
+INSERT INTO t3 VALUES (2), (3), (4)</b></codeblock>
+<p>this query</p>
 <codeblock><b>SELECT t1.* FROM t1 WHERE t1.c1 IN 
-    (SELECT t2.c1 FROM t2, t3 WHERE t2.c1 = t3.c1)</b></codeblock></p>
-<p>should return the following results:  
+    (SELECT t2.c1 FROM t2, t3 WHERE t2.c1 = t3.c1)</b></codeblock>
+<p>should return the following results:</p>
 <codeblock>2
-3</codeblock></p>
-<p>The query satisfies all the requirements for flattening into a join, and
-the statement can be transformed into the following one:  
+3</codeblock>
+<p>The query satisfies all the requirements for flattening into a join, and the
+statement can be transformed into the following one:</p>
 <codeblock><b>SELECT t1.*
 FROM t1, t2, t3
 WHERE t1.c1 = t2.c1
 AND t2.c1 = t3.c1
-AND t1.c1 = t3.c1</b></codeblock></p>
-<p>The following query:  
+AND t1.c1 = t3.c1</b></codeblock>
+<p>The following query:</p>
 <codeblock><b>SELECT t1.*
 FROM t1 WHERE EXISTS
-(SELECT * FROM t2, t3 WHERE t2.c1 = t3.c1 AND t2.c1 = t1.c1)</b></codeblock></p>
-<p>can be transformed into  
+(SELECT * FROM t2, t3 WHERE t2.c1 = t3.c1 AND t2.c1 = t1.c1)</b></codeblock>
+<p>can be transformed into</p>
 <codeblock><b>SELECT t1.*
 FROM t1, t2, t3
 WHERE t1.c1 = t2.c1
 AND t2.c1 = t3.c1
-AND t1.c1 = t3.c1</b></codeblock></p>
+AND t1.c1 = t3.c1</b></codeblock>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform36623.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform36623.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform36623.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform36623.dita Fri Jul 11 20:43:23 2014
@@ -20,57 +20,63 @@ limitations under the License.
 -->
 <concept id="ctuntransform36623" xml:lang="en-us">
 <title>Predicates pushed into views or derived tables</title>
+<shortdesc>An SQL statement that references a view can also include a
+predicate.</shortdesc>
 <prolog><metadata>
 <keywords><indexterm>predicates<indexterm>pushed down into views</indexterm></indexterm>
 </keywords>
 </metadata></prolog>
 <conbody>
-<p>An SQL statement that references a view can also include a predicate. Consider
-the view <i>v2 (a,b)</i>:   <codeblock>CREATE VIEW v2(a,b) AS
+<p>Consider the view <codeph>v2(a,b)</codeph>:</p>
+<codeblock><b>CREATE VIEW v2(a,b) AS
 SELECT sales_person, MAX(sales)
 FROM Sales
-GROUP BY sales_person</codeblock></p>
-<p>The following statement references the view and includes a predicate: 
- <codeblock>SELECT *
+GROUP BY sales_person</b></codeblock>
+<p>The following statement references the view and includes a predicate:</p>
+<codeblock><b>SELECT *
 FROM v2
-WHERE a = 'LUCCHESSI'</codeblock></p>
-<p>When <ph conref="../conrefs.dita#prod/productshortname"></ph> transforms
-that statement by first transforming the view into a derived table, it places
-the predicate at the top level of the new query, outside the scope of the
-derived table:   <codeblock>SELECT a, b 
+WHERE a = 'LUCCHESI'</b></codeblock>
+<p>When <ph conref="../conrefs.dita#prod/productshortname"></ph> transforms that
+statement by first transforming the view into a derived table, it places the
+predicate at the top level of the new query, outside the scope of the derived
+table:</p>
+<codeblock><b>SELECT a, b 
 FROM (SELECT sales_person, MAX(sales) 
    FROM Sales 
-   WHERE sales_person = 'LUCCHESSI' 
+   WHERE sales_person = 'LUCCHESI' 
    GROUP BY sales_person) 
-   v1(a, b)
-</codeblock></p>
-<p>In the example in the preceding section (see <xref href="ctuntransform22576.dita#ctuntransform22576"></xref>), <ph
-conref="../conrefs.dita#prod/productshortname"></ph> was able to flatten the
+   v1(a, b)</b></codeblock>
+<p>In the example in <xref href="ctuntransform22576.dita"/>,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> was able to flatten the
 derived table into the main SELECT, so the predicate in the outer SELECT could
 be evaluated at a useful point in the query. This is not possible in this
-example, because the underlying view does not satisfy all the requirements
-of view flattening.</p>
-<p>However, if the source of all of the column references in a predicate is
-a <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref> in the underlying view or table, <ph conref="../conrefs.dita#prod/productshortname"></ph> is
-able to <i>push</i> the predicate <i>down</i> to the underlying view. Pushing
-down means that the qualification described by the predicate can be evaluated
-when the view is being evaluated. In our example, the column reference in
-the outer predicate, <i>a</i>, in the underlying view is a <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref> to the underlying <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base
+example, because the underlying view does not satisfy all the requirements of
+view flattening.</p>
+<p>However, if the source of all of the column references in a predicate is a
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
+column reference</xref> in the underlying view or table,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> is able to <i>push</i>
+the predicate <i>down</i> to the underlying view. Pushing down means that the
+qualification described by the predicate can be evaluated when the view is being
+evaluated. In our example, the column reference in the outer predicate,
+<codeph>a</codeph>, in the underlying view is a simple column reference to the
+underlying
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform41494">base
 table</xref>. So the final transformation of this statement after predicate
-pushdown is: <codeblock>SELECT a, b 
+pushdown is:</p>
+<codeblock><b>SELECT a, b 
 FROM (SELECT sales_person, MAX(sales) from Sales 
-WHERE sales_person = 'LUCCHESSI' 
-GROUP BY sales_person) v1(a, b)</codeblock></p>
-<p>Without the transformation, <ph conref="../conrefs.dita#prod/productshortname"></ph> would
-have to scan the entire table <i>t1</i> to form all the groups, only to throw
-out all but one of the groups. With the transformation, <ph conref="../conrefs.dita#prod/productshortname"></ph> is
-able to make that qualification part of the derived table.</p>
-<p>If there were a predicate that referenced column <i>b</i>, it could not
-be pushed down, because in the underlying view, column <i>b</i> is not a <xref
-href="ctuntransform13966.dita#ctuntransform13966/rtuntransform13785">simple
-column reference</xref>.</p>
+WHERE sales_person = 'LUCCHESI' 
+GROUP BY sales_person) v1(a, b)</b></codeblock>
+<p>Without the transformation,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> would have to scan the
+entire table <codeph>t1</codeph> to form all the groups, only to throw out all
+but one of the groups. With the transformation,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> is able to make that
+qualification part of the derived table.</p>
+<p>If there were a predicate that referenced column <codeph>b</codeph>, it could
+not be pushed down, because in the underlying view, column <codeph>b</codeph> is
+not a simple column reference.</p>
 <p>Predicate pushdown transformation includes predicates that reference multiple
 tables from an underlying join.</p>
 </conbody>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform37032.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform37032.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform37032.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform37032.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,8 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform37032">
 <title>Transitive closure</title>
+<shortdesc>The transitive property of numbers states that if A = B and B = C,
+then A = C.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Transitive closure</indexterm>
@@ -26,15 +28,12 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>The transitive property of numbers states that if A = B and B = C, then
-A = C.</p>
-<p><ph conref="../conrefs.dita#prod/productshortname"></ph> applies this property to query predicates to add additional
-predicates to the query in order to give the optimizer more information. This
-process is called <i>transitive closure</i>. There are two
-types of transitive closure:  
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> applies this
+property to query predicates to add additional predicates to the query in order
+to give the optimizer more information. This process is called <i>transitive
+closure</i>. There are two types of transitive closure:</p>
 <ul>
-<li>Transitive closure on join clauses  
-<p>Applied first, if applicable</p></li>
+<li>Transitive closure on join clauses (applied first, if applicable)</li>
 <li>Transitive closure on search clauses</li>
-</ul></p>
+</ul>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform47182.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform47182.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform47182.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform47182.dita Fri Jul 11 20:43:23 2014
@@ -18,8 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform47182">
 <title>Flattening VALUES subqueries</title>
+<shortdesc><ph conref="../conrefs.dita#prod/productshortname"></ph> flattens
+VALUES subqueries to improve performance.</shortdesc>
 <prolog>
 </prolog>
 <conbody>
-<p><ph conref="../conrefs.dita#prod/productshortname"></ph> flattens VALUES subqueries to improve performance.</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform55045.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform55045.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform55045.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform55045.dita Fri Jul 11 20:43:23 2014
@@ -18,10 +18,11 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform55045">
 <title>Outer join transformations</title>
+<shortdesc><ph conref="../conrefs.dita#prod/productshortname"></ph> transforms
+OUTER to INNER joins when the predicate filters out all nulls on the join
+column. This transformation can allow more potential query plans and thus better
+performance.</shortdesc>
 <prolog>
 </prolog>
 <conbody>
-<p><ph conref="../conrefs.dita#prod/productshortname"></ph> transforms OUTER to INNER joins when the predicate filters
-out all nulls on the join column. This transformation can allow more potential
-query plans and thus better performance.</p>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform867165.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform867165.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform867165.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform867165.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform867165">
 <title>DISTINCT elimination in IN, ANY, and EXISTS subqueries</title>
+<shortdesc>An IN, ANY, or EXISTS subquery evaluates to true if there is at least
+one row that causes the subquery to evaluate to true. These semantics make a
+DISTINCT within an IN, ANY, or EXISTS subquery unnecessary.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>Subqueries<indexterm>elimination of DISTINCT in IN,
@@ -26,13 +29,11 @@ ANY, and EXISTS subqueries</indexterm></
 </metadata>
 </prolog>
 <conbody>
-<p>An IN, ANY, or EXISTS subquery evaluates to true if there is at least one
-row that causes the subquery to evaluate to true. These semantics make a DISTINCT
-within an IN, ANY, or EXISTS subquery unnecessary. The following two queries
-are equivalent and the first is transformed into the second:   
+<p>The following two queries are equivalent, and the first is transformed into
+the second:</p>
 <codeblock><b>SELECT * FROM t1 WHERE c1 IN
     (SELECT DISTINCT c2 FROM t2 WHERE t1.c3 = t2.c4)
 
 SELECT * FROM t1 WHERE c1 IN
-    (SELECT c2 FROM t2 WHERE t1.c3 = t2.c4)</b></codeblock></p>
+    (SELECT c2 FROM t2 WHERE t1.c3 = t2.c4)</b></codeblock>
 </conbody></concept>

Modified: db/derby/docs/trunk/src/tuning/ctuntransform867201.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctuntransform867201.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctuntransform867201.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctuntransform867201.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
 <concept xml:lang="en-us" id="ctuntransform867201">
 <title>IN/ANY subquery transformation</title>
+<shortdesc>An IN or ANY subquery that is guaranteed to return at most one row
+can be transformed into an equivalent expression subquery (a scalar subquery
+without the IN or ANY). The subquery must not be correlated.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>IN/ANY subquery transformation</indexterm>
@@ -25,26 +28,24 @@ limitations under the License.
 </metadata>
 </prolog>
 <conbody>
-<p>An IN or ANY subquery that is guaranteed to return at most one row can
-be transformed into an equivalent expression subquery (a scalar subquery without
-the IN or ANY). The subquery must not be correlated. Subqueries guaranteed
-to return at most one row are:  
+<p>Subqueries guaranteed to return at most one row are:</p>
 <ul>
 <li>Simple VALUES clauses</li>
 <li>SELECTs returning a non-grouped aggregate</li>
-</ul></p>
-<p>For example:  
-<codeblock><b>WHERE C1 IN (SELECT MIN(c1) FROM T)</b></codeblock></p>
-<p>can be transformed into  
-<codeblock><b>WHERE C1 = (SELECT MIN(c1) FROM T)</b></codeblock></p>
+</ul>
+<p>For example,</p>
+<codeblock><b>WHERE C1 IN (SELECT MIN(c1) FROM T)</b></codeblock>
+<p>can be transformed into</p>
+<codeblock><b>WHERE C1 = (SELECT MIN(c1) FROM T)</b></codeblock>
 <p>This transformation is considered before subquery materialization. If the
-transformation is performed, the subquery becomes materializable. In the example,
-if the IN subquery were not transformed, it would be evaluated anew for each
-row.</p>
+transformation is performed, the subquery becomes materializable. In the
+example, if the IN subquery were not transformed, it would be evaluated anew for
+each row.</p>
 <p>The subquery type transformation is shown in the following table.</p>  
 <table frame="all">
-<title>IN or ANY subquery transformations for subqueries
-that return a single row</title>
+<title>IN or ANY subquery transformations for subqueries that return a single
+row</title>
+<desc>This table shows how IN and ANY subqueries are transformed.</desc>
 <tgroup cols="2" colsep="1" rowsep="1">
 <colspec colname="1" colnum="1" colwidth="50*"/>
 <colspec colname="2" colnum="2" colwidth="50*"/>

Modified: db/derby/docs/trunk/src/tuning/rtuntransform139.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/rtuntransform139.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/rtuntransform139.dita (original)
+++ db/derby/docs/trunk/src/tuning/rtuntransform139.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,9 @@ limitations under the License.
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "../dtd/reference.dtd">
 <reference xml:lang="en-us" id="rtuntransform139">
 <title>BETWEEN transformations</title>
+<shortdesc>A BETWEEN predicate is transformed into equivalent predicates that
+use the <codeph>&gt;=</codeph> and <codeph>&lt;=</codeph> operators, which are
+optimizable.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>BETWEEN transformations</indexterm>
@@ -26,10 +29,9 @@ limitations under the License.
 </metadata>
 </prolog>
 <refbody>
-<section><p>A BETWEEN predicate is transformed into equivalent predicates that use
-the &gt;= and &lt;= operators, which are optimizable. For example:  
-<codeblock><b>flight_date BETWEEN DATE('2005-04-01') and DATE('2005-04-10')</b></codeblock></p></section>
-<section><p>is transformed into  
+<section><p>For example,</p>
+<codeblock><b>flight_date BETWEEN DATE('2005-04-01') and DATE('2005-04-10')</b></codeblock>
+<p>is transformed into</p>
 <codeblock><b>flight_date &gt;= DATE('2005-04-01')
-AND flight_date &gt;= '2005-04-10'</b></codeblock></p></section>
+AND flight_date &gt;= '2005-04-10'</b></codeblock></section>
 </refbody></reference>

Modified: db/derby/docs/trunk/src/tuning/rtuntransform208.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/rtuntransform208.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/rtuntransform208.dita (original)
+++ db/derby/docs/trunk/src/tuning/rtuntransform208.dita Fri Jul 11 20:43:23 2014
@@ -18,6 +18,8 @@ limitations under the License.
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "../dtd/reference.dtd">
 <reference xml:lang="en-us" id="rtuntransform208">
 <title>LIKE transformations</title>
+<shortdesc>This section describes using LIKE transformations as a comparison
+operator.</shortdesc>
 <prolog><metadata>
 <keywords>
 <indexterm>LIKE transformations</indexterm>
@@ -26,8 +28,6 @@ limitations under the License.
 </metadata>
 </prolog>
 <refbody><section>
-<p>This section describes using LIKE transformations as a comparison operator.
-</p>
 <note>LIKE transformations and optimizations are disabled when you use
 locale-based collation. See "Character-based collation in
 <ph conref="../conrefs.dita#prod/productshortname"></ph>" in the

Modified: db/derby/docs/trunk/src/tuning/rtuntransform345.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/rtuntransform345.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/rtuntransform345.dita (original)
+++ db/derby/docs/trunk/src/tuning/rtuntransform345.dita Fri Jul 11 20:43:23 2014
@@ -18,25 +18,27 @@ limitations under the License.
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "../dtd/reference.dtd">
 <reference xml:lang="en-us" id="rtuntransform345">
 <title>Character string beginning with constant</title>
+<shortdesc>A LIKE predicate in which a column is compared to a character string
+that <i>begins</i> with a character constant (not a wildcard) is transformed
+into three predicates: one predicate that uses the LIKE operator, one that
+uses the <codeph>&gt;=</codeph> operator, and one that uses the
+<codeph>&lt;</codeph> operator.</shortdesc>
 <prolog>
 </prolog>
 <refbody>
-<section><p>A LIKE predicate in which a column is compared to a character string that <i>begins</i> with a character constant (not a wildcard) is transformed
-into three predicates: one predicate that uses the LIKE operator, one that
-uses the &gt;= operator, and one that uses the &lt; operator. For example:
-  
-<codeblock><b>country LIKE 'Ch%i%'</b></codeblock></p></section>
-<section><p>becomes   
+<section><p>For example,</p>
+<codeblock><b>country LIKE 'Ch%i%'</b></codeblock>
+<p>becomes</p>
 <codeblock><b>country LIKE 'Ch%i%'
 AND country &gt;= 'Ch'
-AND country &lt; 'Ci'</b></codeblock></p></section>
-<section><p>The first (LIKE) predicate is not optimizable, but the new predicates added
-by the transformation are.</p></section>
-<section><p>When the character string begins with one more character constants and
-ends with a single "%", the first LIKE clause is eliminated. For example:
- 
-<codeblock><b>country LIKE 'Ch%'</b></codeblock></p></section>
-<section><p>becomes  
+AND country &lt; 'Ci'</b></codeblock>
+<p>The first (LIKE) predicate is not optimizable, but the new
+predicates added by the transformation are.</p></section>
+<section><p>When the character string begins with one more character constants
+and ends with a single "%", the first LIKE clause is eliminated. For
+example,</p>
+<codeblock><b>country LIKE 'Ch%'</b></codeblock>
+<p>becomes</p>
 <codeblock><b>country &gt;= 'Ch'
-AND country &lt; 'Ci'</b></codeblock></p></section>
+AND country &lt; 'Ci'</b></codeblock></section>
 </refbody></reference>

Modified: db/derby/docs/trunk/src/tuning/rtuntransform443.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/rtuntransform443.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/rtuntransform443.dita (original)
+++ db/derby/docs/trunk/src/tuning/rtuntransform443.dita Fri Jul 11 20:43:23 2014
@@ -18,18 +18,22 @@ limitations under the License.
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "../dtd/reference.dtd">
 <reference xml:lang="en-us" id="rtuntransform443">
 <title>Character string without wildcards</title>
+<shortdesc>A LIKE predicate is transformed into a predicate that uses the
+<codeph>=</codeph> operator (and a NOT LIKE predicate is transformed into one
+that uses <codeph>&lt;&gt;</codeph>) when the character string does not contain
+any wildcards.</shortdesc>
 <prolog>
 </prolog>
 <refbody>
-<section><p>A LIKE predicate is transformed into a predicate that uses the = operator
-(and a NOT LIKE predicate is transformed into one that uses &lt;&gt;) when
-the character string does not contain any wildcards. For example:   
-<codeblock><b>country LIKE 'Chile'</b></codeblock></p></section>
-<section><p>becomes  
-<codeblock><b>country = 'Chile'</b></codeblock></p></section>
-<section><p>and  
-<codeblock><b>country NOT LIKE 'Chile'</b></codeblock></p></section>
-<section><p>becomes  
-<codeblock><b>country &lt;&gt; 'Chile'</b></codeblock></p></section>
-<section><p>Predicates that use the = operator are <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform19435">optimizable</xref>. Predicates that use the &lt;&gt; operator are <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform26698">sargable</xref>.</p></section>
+<section><p>For example,</p>
+<codeblock><b>country LIKE 'Chile'</b></codeblock>
+<p>becomes</p>
+<codeblock><b>country = 'Chile'</b></codeblock>
+<p>and</p>
+<codeblock><b>country NOT LIKE 'Chile'</b></codeblock>
+<p>becomes</p>
+<codeblock><b>country &lt;&gt; 'Chile'</b></codeblock>
+<p>Predicates that use the <codeph>=</codeph> operator are
+<xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform19435">optimizable</xref>. Predicates that use the &lt;&gt; operator are <xref href="ctuntransform13966.dita#ctuntransform13966/rtuntransform26698">sargable</xref>.</p>
+</section>
 </refbody></reference>

Modified: db/derby/docs/trunk/src/tuning/rtuntransform472.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/rtuntransform472.dita?rev=1609827&r1=1609826&r2=1609827&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/rtuntransform472.dita (original)
+++ db/derby/docs/trunk/src/tuning/rtuntransform472.dita Fri Jul 11 20:43:23 2014
@@ -18,25 +18,26 @@ limitations under the License.
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" "../dtd/reference.dtd">
 <reference xml:lang="en-us" id="rtuntransform472">
 <title>Unknown parameter</title>
+<shortdesc>The situation is similar to those described above when a column is
+compared using the LIKE operator to a parameter whose value is unknown in
+advance (dynamic parameter, join column, and the like).</shortdesc>
 <prolog>
 </prolog>
 <refbody>
-<section><p>'The situation is similar to those described above when a column is compared
-using the LIKE operator to a parameter whose value is unknown in advance (dynamic
-parameter, join column, etc.).</p></section>
-<section><p>In this situation, the LIKE predicate is likewise transformed into three
-predicates: one LIKE predicate, one predicate using the &gt;= operator, and
-one predicate using the &lt; operator. For example:  
-<codeblock><b>country LIKE ?</b></codeblock></p></section>
-<section><p>is transformed into  
+<section><p>In this situation, the LIKE predicate is likewise transformed into
+three predicates: one LIKE predicate, one predicate using the
+<codeph>&gt;=</codeph> operator, and one predicate using the
+<codeph>&lt;</codeph> operator. For example,</p>
+<codeblock><b>country LIKE ?</b></codeblock>
+<p>is transformed into</p>
 <codeblock><b>country LIKE ?
 AND country &gt;= <b><i>InternallyGeneratedParameter</i></b>
-AND country &lt; <b><i>InternallyGeneratedParameter</i></b></b></codeblock></p></section>
-<section><p>where the <i>InternallyGeneratedParameters</i> are calculated
-at the beginning of execution based on the value of the parameter.   
-<note>This transformation can lead to a bad plan if the user passes in
-a string that begins with a wildcard or a nonselective string as the parameter.
+AND country &lt; <b><i>InternallyGeneratedParameter</i></b></b></codeblock>
+<p>where the <i>InternallyGeneratedParameter</i>s are calculated at the
+beginning of execution based on the value of the parameter.</p>
+<p><note>This transformation can lead to a bad plan if the user passes in a
+string that begins with a wildcard or a nonselective string as the parameter.
 Users can work around this possibility by writing the query like this (which
-is not optimizable):  
+is not optimizable):
 <codeblock><b>(country || '') LIKE ?</b></codeblock></note></p></section>
 </refbody></reference>



Mime
View raw message