svn commit - mysqldoc@oter02: r26153 - in trunk: . refman-5.6

[paul.dubois]

Author: pd221994
Date: 2011-05-09 00:37:46 +0200 (Mon, 09 May 2011)
New Revision: 26153

Log:
 r47788@dhcp-adc-twvpn-1-vpnpool-10-154-13-87:  paul | 2011-05-07 10:52:54 -0500
 Some ICP fixups from Olav


Modified:
   svk:merge
   trunk/refman-5.6/optimization.xml

Property changes on: trunk
___________________________________________________________________

Modified: svk:merge
===================================================================


Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 1277 bytes


Modified: trunk/refman-5.6/optimization.xml
===================================================================
--- trunk/refman-5.6/optimization.xml	2011-05-08 06:31:27 UTC (rev 26152)
+++ trunk/refman-5.6/optimization.xml	2011-05-08 22:37:46 UTC (rev 26153)
Changed blocks: 4, Lines Added: 16, Lines Deleted: 17; 3300 bytes

@@ -17897,10 +17897,10 @@
         the MySQL server pushes this part of the
         <literal>WHERE</literal> condition down to the storage engine.
         The storage engine then evaluates the pushed index condition by
-        using the index entry and only if this is satisfied is base row
-        be read. ICP can reduce the number of accesses the storage
-        engine has to do against the base table and the number of
-        accesses the MySQL server has to do against the storage engine.
+        using the index entry and only if this is satisfied is the row
+        read from the table. ICP can reduce the number of times the
+        storage engine must access the base table and the number of
+        times the MySQL server must access the storage engine.
       </para>
 
       <para>

@@ -17958,21 +17958,22 @@
             Test the part of the <literal>WHERE</literal> condition that
             applies to this table and can be checked using only index
             columns. If the condition is not satisfied, proceed to the
-            next row.
+            index tuple for the next row.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Use the index tuple to locate and read the full table row.
+            If the condition is satisfied, use the index tuple to locate
+            and read the full table row.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Test the part of the <literal>WHERE</literal> condition that
-            applies to this table. Accept or reject the row based on the
-            test result.
+            Test the remaining part of the <literal>WHERE</literal>
+            condition that applies to this table. Accept or reject the
+            row based on the test result.
           </para>
         </listitem>
 

@@ -17999,7 +18000,7 @@
 SELECT * FROM people
   WHERE zipcode='95054'
   AND lastname LIKE '%etrunia%'
-  AND address LIKE '%Main Street%'
+  AND address LIKE '%Main Street%';
 </programlisting>
 
       <para>

@@ -18016,18 +18017,16 @@
         <literal>lastname LIKE '%etrunia%'</literal> part before reading
         the full table row. This avoids reading full rows corresponding
         to all index tuples that do not match the
-        <literal>lastname</literal> condition. The full-row test is
-        <quote>pushed down</quote> to take place later than the
-        index-only test.
+        <literal>lastname</literal> condition.
       </para>
 
       <para>
         Index Condition Pushdown is enabled by default; it can be
         controlled with the
-        <literal role="sysvar">engine_condition_pushdown</literal>
-        system variable. This variable also controls table Condition
-        Pushdown as used for NDB; see
-        <xref linkend="condition-pushdown-optimization"/>.
+        <literal role="sysvar">optimizer_switch</literal> system
+        variable by setting the
+        <literal>index_condition_pushdown</literal> flag. See
+        <xref linkend="switchable-optimizations"/>.
       </para>
 
     </section>