svn commit - mysqldoc@docsrva: r193 - in trunk: refman-5.0 refman-5.1

[jstephens]

Author: jstephens
Date: 2005-10-28 12:52:47 +0200 (Fri, 28 Oct 2005)
New Revision: 193

Log:

refman-5.0/introduction.xml,
refman-5.0/optimization.xml,
refman-5.1/optimization.xml
  - Updated info about index_merge and loose index scans (Thanks, SergeyP!)



Modified:
   trunk/refman-5.0/introduction.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.1/optimization.xml

Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml	2005-10-27 17:45:45 UTC (rev 192)
+++ trunk/refman-5.0/introduction.xml	2005-10-28 10:52:47 UTC (rev 193)
@@ -523,14 +523,22 @@
             
             <listitem>
               <para>
-                Better optimization of <literal>OR</literal> over
-                different keys, such as <literal>... WHERE key1=5 OR
-                  key2=6</literal>. (Previously, <literal>OR</literal>
-                was optimized only where both relations involved the
-                same key.) This also applies to other one-to-one
-                comparison operators (<literal>&gt;</literal>,
-                <literal>&lt;</literal>, and so on), as well as
-                <literal>=</literal>. 
+                Use of the <firstterm>Index Merge</firstterm> method to
+                obtain better optimization of <literal>AND</literal> and
+                <literal>OR</literal> relations over different keys.
+                (Previously, these were optimized only where both
+                relations in the <literal>WHERE</literal> clause
+                involved the same key.) This also applies to other
+                one-to-one comparison operators
+                (<literal>&gt;</literal>,
<literal>&lt;</literal>, so
+                on), including <literal>=</literal> and the
+                <literal>IN</literal> operator. This means that MySQL
+                can use multiple indexes in retrieving results for
+                conditions such as <literal>WHERE key1 &gt; 4 OR key2
+                  &lt; 7</literal> and even combinations of conditions
+                such as <literal>WHERE (key1 &gt; 4 OR key2 &lt; 7) AND
+                  (key3 &gt;= 10 OR key4 = 1)</literal>. See
+                <xref linkend="index-merge-optimization"/>.  
               </para>
             </listitem>
             
@@ -668,7 +676,7 @@
               <para>
                 <literal>MIN()</literal> and
<literal>MAX()</literal>
                 with <literal>GROUP BY</literal> are also now better
-                optimized.
+                optimized. See <xref linkend="loose-index-scan"/>.
               </para>
             </listitem>
             

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2005-10-27 17:45:45 UTC (rev 192)
+++ trunk/refman-5.0/optimization.xml	2005-10-28 10:52:47 UTC (rev 193)
@@ -2752,27 +2752,11 @@
         <primary>optimizations</primary>
       </indexterm>
 
-      <remark role="todo">
-        replace following para with this one if ref/ref_or_null doesn't
-        apply.
-      </remark>
-
-<!--  
       <para>
-        The Index Merge method is used to retrieve rows with several 
-        <literal>range</literal> scans and to merge their results into 
-        one.
-      </para> 
--->
-
-      <para>
-        The Index Merge (<literal>index_merge</literal>) method is used
-        to retrieve rows with several <literal>ref</literal>,
-        <literal>ref_or_null</literal>, or
<literal>range</literal>
-        scans and merge the results into one. This method is employed
-        when the table condition is a disjunction of conditions for
-        which <literal>ref</literal>,
<literal>ref_or_null</literal>, or
-        <literal>range</literal> could be used with different keys.
+        The <firstterm>Index Merge</firstterm> method is used to
+        retrieve rows with several <literal>range</literal> scans and to
+        merge their results into one. The merge can produce unions,
+        intersections, or unions-of-intersections of its underlying scans.
       </para>
 
       <para>

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2005-10-27 17:45:45 UTC (rev 192)
+++ trunk/refman-5.1/optimization.xml	2005-10-28 10:52:47 UTC (rev 193)
@@ -2752,38 +2752,14 @@
         <primary>optimizations</primary>
       </indexterm>
 
-      <remark role="todo">
-        replace following para with this one if ref/ref_or_null doesn't
-        apply.
-      </remark>
-
-<!--  
       <para>
-        The Index Merge method is used to retrieve rows with several 
-        <literal>range</literal> scans and to merge their results into 
-        one.
-      </para> 
--->
-
-      <para>
-        The Index Merge (<literal>index_merge</literal>) method is used
-        to retrieve rows with several <literal>ref</literal>,
-        <literal>ref_or_null</literal>, or
<literal>range</literal>
-        scans and merge the results into one. This method is employed
-        when the table condition is a disjunction of conditions for
-        which <literal>ref</literal>,
<literal>ref_or_null</literal>, or
-        <literal>range</literal> could be used with different keys.
+        The <firstterm>Index Merge</firstterm> method is used to
+        retrieve rows with several <literal>range</literal> scans and to
+        merge their results into one. The merge can produce unions,
+        intersections, or unions-of-intersections of its underlying scans.
       </para>
 
       <para>
-        <emphasis role="bold">Note</emphasis>: If you have upgraded from
-        a previous version of MySQL, you should be aware that this type
-        of join optimization represents a significant change in behavior
-        with regard to indexes. (Before version 5.0, MySQL was able to
-        use at most only one index for each referenced table.)
-      </para>
-
-      <para>
         In <literal>EXPLAIN</literal> output, this method appears as
         <literal>index_merge</literal> in the
<literal>type</literal>
         column. In this case, the <literal>key</literal> column contains
@@ -3425,9 +3401,9 @@
       <title id="title-nested-joins">&title-nested-joins;</title>
 
       <para>
-        In MySQL &current-series;, the syntax for expressing joins
-        allows nested joins. The following discussion refers to the join
-        syntax described in <xref linkend="join"/>.
+        The syntax for expressing joins allows nested joins. The following 
+        discussion refers to the join syntax described in 
+        <xref linkend="join"/>.
       </para>
 
       <para>
@@ -6549,7 +6525,7 @@
 
         <listitem>
           <para>
-            In MySQL/InnoDB &current-series;, <literal>InnoDB</literal>
+            In MySQL/InnoDB, <literal>InnoDB</literal> 
             tables use a more compact storage format. In earlier
             versions of MySQL, InnoDB records contain some redundant
             information, such as the number of columns and the length of