svn commit - mysqldoc@docsrva: r1015 - trunk/internals

[jon]

Author: jstephens
Date: 2006-01-24 09:18:21 +0100 (Tue, 24 Jan 2006)
New Revision: 1015

Log:


Added new info about index_merge to internals doc. (Thanks, Sergei!)



Modified:
   trunk/internals/internals.xml

Modified: trunk/internals/internals.xml
===================================================================
--- trunk/internals/internals.xml	2006-01-24 05:19:01 UTC (rev 1014)
+++ trunk/internals/internals.xml	2006-01-24 08:18:21 UTC (rev 1015)
@@ -3881,6 +3881,13 @@
           join type) pick a driver based on the first index that was
           created.
         </para>
+    
+        <para>
+          The optimizer can also choose to perform an
+          <literal>index_merge</literal> index intersection, as
+          described here: 
+          <ulink url="http://dev.mysql.com/doc/refman/5.0/en/index-merge-intersection.html"/>.
+        </para>
       </listitem>
 
     </orderedlist>
@@ -3925,26 +3932,15 @@
 <programlisting>
 Use a sequential scan.
 </programlisting>
-
+    
     <para>
-      In theory there is another choice if both column1 and column2 are
-      indexed:
+      There is also an option to use index merge under such
+      circumstances. See <xref linkend="index-merge-optimizer"/> and
+      <ulink url="http://dev.mysql.com/doc/refman/5.1/en/index-merge-optimization.html"/> 
+      for more information. 
     </para>
 
-<programlisting>
-index search for the first condition,
-index search for the second condition,
-merge the two result sets
-</programlisting>
-
-<!--  Isn't that code what is now described in the Index Merge section? -->
-
     <para>
-      MySQL never does that. But MySQL will do that in future, the code
-      for doing so already exists.
-    </para>
-
-    <para>
       The above warning does not apply if the same column is used in
       both conditions. For example:
     </para>
@@ -3958,27 +3954,8 @@
       range search. This subject will be revisited during the discussion
       of the <literal>IN</literal> predicate.
     </para>
-
+    
     <para>
-      <emphasis role="bold">AND plus OR</emphasis>
-    </para>
-
-    <para>
-      Consider this search expression:
-    </para>
-
-<programlisting>
-WHERE column1 = 5 AND (column2 = 5 OR column3 = 5)
-</programlisting>
-
-    <para>
-      If <literal>column1</literal> is indexed, then the optimizer will
-      choose to use the index. In other words, the <quote>sequential
-      scan if <literal>OR</literal></quote> rule does not apply if the
-      <literal>OR</literal> is subordinate to an <literal>AND</literal>.
-    </para>
-
-    <para>
       <emphasis role="bold">UNION</emphasis>
     </para>