svn commit - mysqldoc@docsrva: r11295 - in trunk: refman-5.1 refman-6.0

[jon]

Author: jstephens
Date: 2008-07-21 14:17:16 +0200 (Mon, 21 Jul 2008)
New Revision: 11295

Log:

Replaced example query that didn't work as edvertised

Fixes Docs Bug #37658



Modified:
   trunk/refman-5.1/partitioning.xml
   trunk/refman-6.0/partitioning.xml


Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2008-07-21 09:57:06 UTC (rev 11294)
+++ trunk/refman-5.1/partitioning.xml	2008-07-21 12:17:16 UTC (rev 11295)
Changed blocks: 1, Lines Added: 8, Lines Deleted: 8; 1546 bytes

@@ -990,14 +990,14 @@
           <para>
             You frequently run queries that depend directly on the
             column used for partitioning the table. For example, when
-            executing a query such as <literal>SELECT COUNT(*) FROM
-            employees WHERE YEAR(separated) = 2000 GROUP BY
-            store_id;</literal>, MySQL can quickly determine that only
-            partition <literal>p2</literal> needs to be scanned because
-            the remaining partitions cannot contain any records
-            satisfying the <literal>WHERE</literal> clause. See
-            <xref linkend="partitioning-pruning"/>, for more information
-            about how this is accomplished.
+            executing a query such as <literal>EXPLAIN PARTITIONS SELECT
+            COUNT(*) FROM employees WHERE separated BETWEEN '2000-01-01'
+            AND '2000-12-31' GROUP BY store_id;</literal>, MySQL can
+            quickly determine that only partition <literal>p2</literal>
+            needs to be scanned because the remaining partitions cannot
+            contain any records satisfying the <literal>WHERE</literal>
+            clause. See <xref linkend="partitioning-pruning"/>, for more
+            information about how this is accomplished.
           </para>
         </listitem>
 


Modified: trunk/refman-6.0/partitioning.xml
===================================================================
--- trunk/refman-6.0/partitioning.xml	2008-07-21 09:57:06 UTC (rev 11294)
+++ trunk/refman-6.0/partitioning.xml	2008-07-21 12:17:16 UTC (rev 11295)
Changed blocks: 1, Lines Added: 8, Lines Deleted: 8; 1546 bytes

@@ -957,14 +957,14 @@
           <para>
             You frequently run queries that depend directly on the
             column used for partitioning the table. For example, when
-            executing a query such as <literal>SELECT COUNT(*) FROM
-            employees WHERE YEAR(separated) = 2000 GROUP BY
-            store_id;</literal>, MySQL can quickly determine that only
-            partition <literal>p2</literal> needs to be scanned because
-            the remaining partitions cannot contain any records
-            satisfying the <literal>WHERE</literal> clause. See
-            <xref linkend="partitioning-pruning"/>, for more information
-            about how this is accomplished.
+            executing a query such as <literal>EXPLAIN PARTITIONS SELECT
+            COUNT(*) FROM employees WHERE separated BETWEEN '2000-01-01'
+            AND '2000-12-31' GROUP BY store_id;</literal>, MySQL can
+            quickly determine that only partition <literal>p2</literal>
+            needs to be scanned because the remaining partitions cannot
+            contain any records satisfying the <literal>WHERE</literal>
+            clause. See <xref linkend="partitioning-pruning"/>, for more
+            information about how this is accomplished.
           </para>
         </listitem>