List:Commits« Previous MessageNext Message »
From:jon.stephens Date:October 25 2010 11:37am
Subject:svn commit - mysqldoc@docsrva: r23360 - in trunk: refman-5.1 refman-5.5 refman-5.6 refman-6.0
View as plain text  
Author: jstephens
Date: 2010-10-25 13:37:17 +0200 (Mon, 25 Oct 2010)
New Revision: 23360

Log:

Merge recent edits to 6.0 version

Harmonise differences



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


Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2010-10-25 08:00:45 UTC (rev 23359)
+++ trunk/refman-5.1/partitioning.xml	2010-10-25 11:37:17 UTC (rev 23360)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1001 bytes

@@ -984,7 +984,7 @@
         regular (in-store) workers, three-digit codes are used for
         office and support personnel, and four-digit codes are used for
         management positions—you could create the partitioned
-        table using the following:
+        table using the following statement:
       </para>
 
 <programlisting>

@@ -5262,7 +5262,7 @@
       the subpartitioning column or columns be specified explicitly,
       unlike the case with <literal>PARTITION BY KEY</literal>, where it
       can be omitted (in which case the table&apos;s primary key column
-      is used by default). Consider table created by this statement:
+      is used by default). Consider the table created by this statement:
     </para>
 
 <programlisting>


Modified: trunk/refman-5.5/partitioning.xml
===================================================================
--- trunk/refman-5.5/partitioning.xml	2010-10-25 08:00:45 UTC (rev 23359)
+++ trunk/refman-5.5/partitioning.xml	2010-10-25 11:37:17 UTC (rev 23360)
Changed blocks: 5, Lines Added: 9, Lines Deleted: 9; 2537 bytes

@@ -639,7 +639,7 @@
 </programlisting>
 
     <para>
-      Beginning with MySQL 5.5.0, it is also possible to use a
+      In MySQL &current-series;, it is also possible to use a
       <literal role="type">DATE</literal> or
       <literal role="type">DATETIME</literal> column as the partitioning
       column using <literal>RANGE COLUMNS</literal> and <literal>LIST

@@ -727,10 +727,10 @@
     <para>
       MySQL partitioning is optimized for use with the
       <literal role="func">TO_DAYS()</literal>,
-      <literal role="func">YEAR()</literal>, and (beginning with MySQL
-      5.5.0) <literal role="func">TO_SECONDS()</literal> functions.
-      However, you can use other date and time functions that return an
-      integer or <literal>NULL</literal>, such as
+      <literal role="func">YEAR()</literal>, and
+      <literal role="func">TO_SECONDS()</literal> functions. However,
+      you can use other date and time functions that return an integer
+      or <literal>NULL</literal>, such as
       <literal role="func">WEEKDAY()</literal>,
       <literal role="func">DAYOFYEAR()</literal>, or
       <literal role="func">MONTH()</literal>. See

@@ -938,7 +938,7 @@
         regular (in-store) workers, three-digit codes are used for
         office and support personnel, and four-digit codes are used for
         management positions&mdash;you could create the partitioned
-        table using the following:
+        table using the following statement:
       </para>
 
 <programlisting>

@@ -3927,8 +3927,8 @@
     </important>
 
     <para>
-      Beginning with MySQL 5.5.0, it is possible to delete rows from one
-      or more selected partitions using
+      Beginning with MySQL 5.5.0, it is possible to delete all rows from
+      one or more selected partitions using
       <literal role="stmt" condition="alter-table">ALTER TABLE ...
       TRUNCATE PARTITION</literal>.
     </para>

@@ -6207,7 +6207,7 @@
       the subpartitioning column or columns be specified explicitly,
       unlike the case with <literal>PARTITION BY KEY</literal>, where it
       can be omitted (in which case the table&apos;s primary key column
-      is used by default). Consider table created by this statement:
+      is used by default). Consider the table created by this statement:
     </para>
 
 <programlisting>


Modified: trunk/refman-5.6/partitioning.xml
===================================================================
--- trunk/refman-5.6/partitioning.xml	2010-10-25 08:00:45 UTC (rev 23359)
+++ trunk/refman-5.6/partitioning.xml	2010-10-25 11:37:17 UTC (rev 23360)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1001 bytes

@@ -937,7 +937,7 @@
         regular (in-store) workers, three-digit codes are used for
         office and support personnel, and four-digit codes are used for
         management positions&mdash;you could create the partitioned
-        table using the following:
+        table using the following statement:
       </para>
 
 <programlisting>

@@ -6656,7 +6656,7 @@
       the subpartitioning column or columns be specified explicitly,
       unlike the case with <literal>PARTITION BY KEY</literal>, where it
       can be omitted (in which case the table&apos;s primary key column
-      is used by default). Consider table created by this statement:
+      is used by default). Consider the table created by this statement:
     </para>
 
 <programlisting>


Modified: trunk/refman-6.0/partitioning.xml
===================================================================
--- trunk/refman-6.0/partitioning.xml	2010-10-25 08:00:45 UTC (rev 23359)
+++ trunk/refman-6.0/partitioning.xml	2010-10-25 11:37:17 UTC (rev 23360)
Changed blocks: 72, Lines Added: 832, Lines Deleted: 843; 85922 bytes

@@ -82,14 +82,6 @@
   </para>
 
   <para>
-    MySQL Community binaries provided by Oracle Corporation include
-    partitioning support. For information about partitioning support
-    offered in commercial MySQL Server binaries, see
-    <ulink url="&base-url-enterprise;server.html"><citetitle>MySQL
-    Enterprise Server 5.1</citetitle></ulink>, on the MySQL Web site.
-  </para>
-
-  <para>
     MySQL &current-series; Community binaries provided by Oracle include
     partitioning support. For information about partitioning support
     offered in commercial MySQL Server binaries, see <citetitle>MySQL

@@ -105,6 +97,12 @@
   </para>
 
   <para>
+    If your MySQL binary is built with partitioning support, nothing
+    further needs to be done to enable it (for example, no special
+    entries are required in your <filename>my.cnf</filename> file).
+  </para>
+
+  <para>
     If you want to disable partitioning support, you can start the MySQL
     Server with the <option role="mysqld">--skip-partition</option>
     option, in which case the value of

@@ -170,55 +168,54 @@
     <para>
       Other sources of information about user-defined partitioning in
       MySQL include the following:
+    </para>
 
-      <itemizedlist>
+  </formalpara>
 
-        <listitem>
-          <para>
-            <ulink url="&base-url-forum-list;?106">MySQL Partitioning
-            Forum</ulink>
-          </para>
+  <itemizedlist>
 
-          <para>
-            This is the official discussion forum for those interested
-            in or experimenting with MySQL Partitioning technology. It
-            features announcements and updates from MySQL developers and
-            others. It is monitored by members of the Partitioning
-            Development and Documentation Teams.
-          </para>
-        </listitem>
+    <listitem>
+      <para>
+        <ulink url="&base-url-forum-list;?106">MySQL Partitioning
+        Forum</ulink>
+      </para>
 
-        <listitem>
-          <para>
-            <ulink url="http://mikaelronstrom.blogspot.com/">Mikael
-            Ronström's Blog</ulink>
-          </para>
+      <para>
+        This is the official discussion forum for those interested in or
+        experimenting with MySQL Partitioning technology. It features
+        announcements and updates from MySQL developers and others. It
+        is monitored by members of the Partitioning Development and
+        Documentation Teams.
+      </para>
+    </listitem>
 
-          <para>
-            MySQL Partitioning Architect and Lead Developer Mikael
-            Ronström frequently posts articles here concerning his work
-            with MySQL Partitioning and MySQL Cluster.
-          </para>
-        </listitem>
+    <listitem>
+      <para>
+        <ulink url="http://mikaelronstrom.blogspot.com/">Mikael
+        Ronström's Blog</ulink>
+      </para>
 
-        <listitem>
-          <para>
-            <ulink url="http://www.planetmysql.org/">PlanetMySQL</ulink>
-          </para>
+      <para>
+        MySQL Partitioning Architect and Lead Developer Mikael Ronström
+        frequently posts articles here concerning his work with MySQL
+        Partitioning and MySQL Cluster.
+      </para>
+    </listitem>
 
-          <para>
-            A MySQL news site featuring MySQL-related blogs, which
-            should be of interest to anyone using my MySQL. We encourage
-            you to check here for links to blogs kept by those working
-            with MySQL Partitioning, or to have your own blog added to
-            those covered.
-          </para>
-        </listitem>
+    <listitem>
+      <para>
+        <ulink url="http://www.planetmysql.org/">PlanetMySQL</ulink>
+      </para>
 
-      </itemizedlist>
-    </para>
+      <para>
+        A MySQL news site featuring MySQL-related blogs, which should be
+        of interest to anyone using my MySQL. We encourage you to check
+        here for links to blogs kept by those working with MySQL
+        Partitioning, or to have your own blog added to those covered.
+      </para>
+    </listitem>
 
-  </formalpara>
+  </itemizedlist>
 
   <para>
     MySQL &current-series; binaries are available from

@@ -349,13 +346,11 @@
       or even in the same database.
     </para>
 
-    <note>
-      <para>
-        MySQL partitioning cannot be used with the
-        <literal>MERGE</literal>, <literal>CSV</literal>, or
-        <literal>FEDERATED</literal> storage engines.
-      </para>
-    </note>
+    <para>
+      MySQL partitioning cannot be used with the
+      <literal>MERGE</literal>, <literal>CSV</literal>, or
+      <literal>FEDERATED</literal> storage engines.
+    </para>
 
     <para>
       To employ a particular storage engine for a partitioned table, it

@@ -376,13 +371,11 @@
     PARTITIONS 6;
 </programlisting>
 
-    <note>
-      <para>
-        Each <literal>PARTITION</literal> clause can include a
-        <literal>[STORAGE] ENGINE</literal> option, but in MySQL
-        &current-series; this has no effect.
-      </para>
-    </note>
+    <para>
+      Each <literal>PARTITION</literal> clause can include a
+      <literal>[STORAGE] ENGINE</literal> option, but in MySQL
+      &current-series; this has no effect.
+    </para>
 
     <important>
       <para>

@@ -400,23 +393,21 @@
       <literal>PARTITION</literal> clause of the
       <literal role="stmt">CREATE TABLE</literal> statement used to
       create the partitioned table.
+    </para>
 
-      <note>
-        <para>
-          The <literal>DATA DIRECTORY</literal> and <literal>INDEX
-          DIRECTORY</literal> options have no effect when defining
-          partitions for tables using the <literal>InnoDB</literal>
-          storage engine.
-        </para>
+    <para>
+      The <literal>DATA DIRECTORY</literal> and <literal>INDEX
+      DIRECTORY</literal> options have no effect when defining
+      partitions for tables using the <literal>InnoDB</literal> storage
+      engine.
+    </para>
 
-        <para>
-          <literal>DATA DIRECTORY</literal> and <literal>INDEX
-          DIRECTORY</literal> are not supported for individual
-          partitions or subpartitions on Windows. Beginning with MySQL
-          6.0.5, these options are ignored on Windows, except that a
-          warning is generated. (Bug#30459)
-        </para>
-      </note>
+    <para>
+      <literal>DATA DIRECTORY</literal> and <literal>INDEX
+      DIRECTORY</literal> are not supported for individual partitions or
+      subpartitions on Windows. Beginning with MySQL 6.0.5, these
+      options are ignored on Windows, except that a warning is
+      generated. (Bug#30459)
     </para>
 
     <para>

@@ -433,25 +424,26 @@
     </indexterm>
 
     <para>
-      Some of the advantages of partitioning include:
+      Some advantages of partitioning are listed here:
     </para>
 
     <itemizedlist>
 
       <listitem>
         <para>
-          Being able to store more data in one table than can be held on
-          a single disk or file system partition.
+          Partitioning makes it possible to store more data in one table
+          than can be held on a single disk or file system partition.
         </para>
       </listitem>
 
       <listitem>
         <para>
           Data that loses its usefulness can often be easily removed
-          from the table by dropping the partition containing only that
-          data. Conversely, the process of adding new data can in some
-          cases be greatly facilitated by adding a new partition
-          specifically for that data.
+          from a partitioned table by dropping the partition (or
+          partitions) containing only that data. Conversely, the process
+          of adding new data can in some cases be greatly facilitated by
+          adding one or more new partitions for storing specifically
+          that data.
         </para>
       </listitem>
 

@@ -459,14 +451,16 @@
         <para>
           Some queries can be greatly optimized in virtue of the fact
           that data satisfying a given <literal>WHERE</literal> clause
-          can be stored only on one or more partitions, thereby
-          excluding any remaining partitions from the search. Because
-          partitions can be altered after a partitioned table has been
-          created, you can reorganize your data to enhance frequent
-          queries that may not have been so when the partitioning scheme
-          was first set up. This capability is sometimes referred to as
-          <firstterm>partition pruning</firstterm>. For more
-          information, see <xref linkend="partitioning-pruning"/>.
+          can be stored only on one or more partitions, which
+          automatically excluding any remaining partitions from the
+          search. Because partitions can be altered after a partitioned
+          table has been created, you can reorganize your data to
+          enhance frequent queries that may not have been often used
+          when the partitioning scheme was first set up. This ability to
+          exclude non-matching partitions (and thus any rows they
+          contain) is often referred to as <firstterm>partition
+          pruning</firstterm>. For more information, see
+          <xref linkend="partitioning-pruning"/>.
         </para>
       </listitem>
 

@@ -507,7 +501,7 @@
 
     <para>
       Be sure to check this section and chapter frequently for updates
-      as Partitioning development continues.
+      as MySQL Partitioning development continues.
     </para>
 
   </section>

@@ -523,7 +517,8 @@
 
     <para>
       This section discusses the types of partitioning which are
-      available in MySQL &current-series;. These include:
+      available in MySQL &current-series;. These include the types
+      listed here:
     </para>
 
     <itemizedlist>

@@ -615,8 +610,10 @@
 
     <para>
       A very common use of database partitioning is to segregate data by
-      date. It is not difficult in MySQL to create partitioning schemes
-      based on <literal role="type">DATE</literal>,
+      date. Some database systems support explicit date partitioning,
+      which MySQL does not implement in &current-series;. However, it is
+      not difficult in MySQL to create partitioning schemes based on
+      <literal role="type">DATE</literal>,
       <literal role="type">TIME</literal>, or
       <literal role="type">DATETIME</literal> columns, or based on
       expressions making use of such columns.

@@ -655,11 +652,36 @@
     <para>
       MySQL's other partitioning types, however, require a partitioning
       expression that yields an integer value or
-      <literal>NULL</literal>.
+      <literal>NULL</literal>. If you wish to use date-based
+      partitioning by <literal>RANGE</literal>, <literal>LIST</literal>,
+      <literal>HASH</literal>, or <literal>LINEAR HASH</literal>, you
+      can simply employ a function that operates on a
+      <literal role="type">DATE</literal>,
+      <literal role="type">TIME</literal>, or
+      <literal role="type">DATETIME</literal> column and returns such a
+      value, as shown here:
     </para>
 
+<programlisting>
+    CREATE TABLE members (
+    firstname VARCHAR(25) NOT NULL,
+    lastname VARCHAR(25) NOT NULL,
+    username VARCHAR(16) NOT NULL,
+    email VARCHAR(35),
+    joined DATE NOT NULL
+)
+PARTITION BY RANGE( YEAR(joined) ) (
+    PARTITION p0 VALUES LESS THAN (1960),
+    PARTITION p1 VALUES LESS THAN (1970),
+    PARTITION p2 VALUES LESS THAN (1980),
+    PARTITION p3 VALUES LESS THAN (1990),
+    PARTITION p4 VALUES LESS THAN MAXVALUE
+);
+</programlisting>
+
     <para>
-      Additional examples of partitioning using dates may be found here:
+      Additional examples of partitioning using dates may be found in
+      the following sections of this chapter:
     </para>
 
     <itemizedlist>

@@ -685,7 +707,8 @@
     </itemizedlist>
 
     <para>
-      For more complex examples of date-based partitioning, see:
+      For more complex examples of date-based partitioning, see the
+      following sections:
     </para>
 
     <itemizedlist>

@@ -917,7 +940,7 @@
         example&mdash;assuming that two-digit job codes are used for
         regular (in-store) workers, three-digit codes are used for
         office and support personnel, and four-digit codes are used for
-        management positions&mdash;you could create this partitioned
+        management positions&mdash;you could create the partitioned
         table using the following statement:
       </para>
 

@@ -1040,7 +1063,8 @@
       </note>
 
       <para>
-        Range partitioning is particularly useful when:
+        Range partitioning is particularly useful when one or more of
+        the following conditions is true:
       </para>
 
       <itemizedlist>

@@ -1242,11 +1266,12 @@
       <para>
         List partitioning in MySQL is similar to range partitioning in
         many ways. As in partitioning by <literal>RANGE</literal>, each
-        partition must be explicitly defined. The chief difference is
-        that, in list partitioning, each partition is defined and
-        selected based on the membership of a column value in one of a
-        set of value lists, rather than in one of a set of contiguous
-        ranges of values. This is done by using <literal>PARTITION BY
+        partition must be explicitly defined. The chief difference
+        between the two types of partitioning is that, in list
+        partitioning, each partition is defined and selected based on
+        the membership of a column value in one of a set of value lists,
+        rather than in one of a set of contiguous ranges of values. This
+        is done by using <literal>PARTITION BY
         LIST(<replaceable>expr</replaceable>)</literal> where
         <replaceable>expr</replaceable> is a column value or an
         expression based on a column value and returning an integer

@@ -2520,8 +2545,8 @@
         In other words, the more closely the graph of the column value
         <foreignphrase>versus</foreignphrase> the value of the
         expression follows a straight line as traced by the equation
-        <literal>y=<replaceable>n</replaceable>x</literal> where
-        <replaceable>n</replaceable> is some nonzero constant, the
+        <literal>y=<replaceable>c</replaceable>x</literal> where
+        <replaceable>c</replaceable> is some nonzero constant, the
         better the expression is suited to hashing. This has to do with
         the fact that the more nonlinear an expression is, the more
         uneven the distribution of data among the partitions it tends to

@@ -2710,6 +2735,7 @@
           Suppose that the table <literal>t1</literal>, using linear
           hash partitioning and having 6 partitions, is created using
           this statement:
+        </para>
 
 <programlisting>
 CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)

@@ -2717,11 +2743,13 @@
     PARTITIONS 6;
 </programlisting>
 
+        <para>
           Now assume that you want to insert two records into
           <literal>t1</literal> having the <literal>col3</literal>
           column values <literal>'2003-04-14'</literal> and
           <literal>'1998-10-19'</literal>. The partition number for the
           first of these is determined as follows:
+        </para>
 
 <programlisting>
 <replaceable>V</replaceable> = POWER(2, CEILING( LOG(2,6) )) = 8

@@ -2732,8 +2760,10 @@
 (<emphasis>3 &gt;= 6 is FALSE: record stored in partition #3</emphasis>)
 </programlisting>
 
+        <para>
           The number of the partition where the second record is stored
           is calculated as shown here:
+        </para>
 
 <programlisting>
 <replaceable>V</replaceable> = 8

@@ -2749,7 +2779,6 @@
 
 (<emphasis>2 &gt;= 6 is FALSE: record stored in partition #2</emphasis>)
 </programlisting>
-        </para>
 
         <para>
           The advantage in partitioning by linear hash is that the

@@ -2789,7 +2818,7 @@
       <para>
         The syntax rules for <literal>CREATE TABLE ... PARTITION BY
         KEY</literal> are similar to those for creating a table that is
-        partitioned by hash. The major differences are that:
+        partitioned by hash. The major differences are listed here:
       </para>
 
       <itemizedlist>

@@ -2877,15 +2906,10 @@
           <para>
             The preceding statement would <emphasis>not</emphasis> be
             valid, were a different partitioning type to be specified.
-
-            <note>
-              <para>
-                In this case, simply using <literal>PARTITION BY
-                KEY()</literal> would also be valid and have the same
-                effect as <literal>PARTITION BY KEY(s1)</literal>, since
-                <literal>s1</literal> is the table's primary key.
-              </para>
-            </note>
+            (In this case, simply using <literal>PARTITION BY
+            KEY()</literal> would also be valid and have the same effect
+            as <literal>PARTITION BY KEY(s1)</literal>, since
+            <literal>s1</literal> is the table's primary key.)
           </para>
 
           <para>

@@ -3046,7 +3070,7 @@
 </programlisting>
 
       <para>
-        Some syntactical items of note:
+        Some syntactical items of note are listed here:
       </para>
 
       <itemizedlist>

@@ -3102,6 +3126,7 @@
             For example, the following <literal role="stmt">CREATE
             TABLE</literal> statement is valid in MySQL
             &current-series;:
+          </para>
 
 <programlisting>
 CREATE TABLE ts (id INT, purchased DATE)

@@ -3121,7 +3146,6 @@
         )
     );
 </programlisting>
-          </para>
         </listitem>
 
       </itemizedlist>

@@ -3354,7 +3378,10 @@
           inserted into the lowest partition. For example, consider
           these two tables in a database named <literal>p</literal>,
           created as follows:
+        </para>
 
+      </formalpara>
+
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE t1 (</userinput>
     -&gt;     <userinput>c1 INT,</userinput>

@@ -3380,11 +3407,13 @@
 Query OK, 0 rows affected (0.09 sec)
 </programlisting>
 
-          You can see the partitions created by these two
-          <literal role="stmt">CREATE TABLE</literal> statements using
-          the following query against the
-          <literal role="is">PARTITIONS</literal> table in the
-          <literal>INFORMATION_SCHEMA</literal> database:
+      <para>
+        You can see the partitions created by these two
+        <literal role="stmt">CREATE TABLE</literal> statements using the
+        following query against the
+        <literal role="is">PARTITIONS</literal> table in the
+        <literal>INFORMATION_SCHEMA</literal> database:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH</userinput>

@@ -3404,12 +3433,14 @@
 7 rows in set (0.00 sec)
 </programlisting>
 
-          (For more information about this table, see
-          <xref linkend="partitions-table"/>.) Now let us populate each
-          of these tables with a single row containing a
-          <literal>NULL</literal> in the column used as the partitioning
-          key, and verify that the rows were inserted using a pair of
-          <literal role="stmt">SELECT</literal> statements:
+      <para>
+        (For more information about this table, see
+        <xref linkend="partitions-table"/>.) Now let us populate each of
+        these tables with a single row containing a
+        <literal>NULL</literal> in the column used as the partitioning
+        key, and verify that the rows were inserted using a pair of
+        <literal role="stmt">SELECT</literal> statements:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>INSERT INTO t1 VALUES (NULL, 'mothra');</userinput>

@@ -3435,10 +3466,12 @@
 1 row in set (0.00 sec)
 </programlisting>
 
-          You can see which partitions are used to store the inserted
-          rows by rerunning the previous query against
-          <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal> and
-          inspecting the output:
+      <para>
+        You can see which partitions are used to store the inserted rows
+        by rerunning the previous query against
+        <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal> and
+        inspecting the output:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH</userinput>

@@ -3458,10 +3491,12 @@
 7 rows in set (0.01 sec)
 </programlisting>
 
-          You can also demonstrate that these rows were stored in the
-          lowest partition of each table by dropping these partitions,
-          and then re-running the <literal role="stmt">SELECT</literal>
-          statements:
+      <para>
+        You can also demonstrate that these rows were stored in the
+        lowest partition of each table by dropping these partitions, and
+        then re-running the <literal role="stmt">SELECT</literal>
+        statements:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>ALTER TABLE t1 DROP PARTITION p0;</userinput>

@@ -3477,17 +3512,17 @@
 Empty set (0.00 sec)
 </programlisting>
 
-          (For more information on <literal>ALTER TABLE ... DROP
-          PARTITION</literal>, see <xref linkend="alter-table"/>.)
-        </para>
+      <para>
+        (For more information on <literal>ALTER TABLE ... DROP
+        PARTITION</literal>, see <xref linkend="alter-table"/>.)
+      </para>
 
-      </formalpara>
-
       <para>
         <literal>NULL</literal> is also treated in this way for
         partitioning expressions that use SQL functions. Suppose that we
         define a table using a <literal role="stmt">CREATE
         TABLE</literal> statement such as this one:
+      </para>
 
 <programlisting>
 CREATE TABLE tndate (

@@ -3501,6 +3536,7 @@
 );
 </programlisting>
 
+      <para>
         As with other MySQL functions,
         <literal role="func">YEAR(NULL)</literal> returns
         <literal>NULL</literal>. A row with a <literal>dt</literal>

@@ -3523,7 +3559,10 @@
           explicitly use <literal>NULL</literal> in a value list rejects
           rows resulting in a <literal>NULL</literal> value for the
           partitioning expression, as shown in this example:
+        </para>
 
+      </formalpara>
+
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE ts1 (</userinput>
     -&gt;     <userinput>c1 INT,</userinput>

@@ -3543,13 +3582,15 @@
 <errortext>ERROR 1504 (HY000): Table has no partition for value NULL</errortext>
 </programlisting>
 
-          Only rows having a <literal>c1</literal> value between
-          <literal>0</literal> and <literal>8</literal> inclusive can be
-          inserted into <literal>ts1</literal>. <literal>NULL</literal>
-          falls outside this range, just like the number
-          <literal>9</literal>. We can create tables
-          <literal>ts2</literal> and <literal>ts3</literal> having value
-          lists containing <literal>NULL</literal>, as shown here:
+      <para>
+        Only rows having a <literal>c1</literal> value between
+        <literal>0</literal> and <literal>8</literal> inclusive can be
+        inserted into <literal>ts1</literal>. <literal>NULL</literal>
+        falls outside this range, just like the number
+        <literal>9</literal>. We can create tables
+        <literal>ts2</literal> and <literal>ts3</literal> having value
+        lists containing <literal>NULL</literal>, as shown here:
+      </para>
 
 <programlisting>
 mysql&gt; CREATE TABLE ts2 (

@@ -3576,15 +3617,17 @@
 Query OK, 0 rows affected (0.01 sec)
 </programlisting>
 
-          When defining value lists for partitioning, you can (and
-          should) treat <literal>NULL</literal> just as you would any
-          other value. For example, both <literal>VALUES IN
-          (NULL)</literal> and <literal>VALUES IN (1, 4, 7,
-          NULL)</literal> are valid, as are <literal>VALUES IN (1, NULL,
-          4, 7)</literal>, <literal>VALUES IN (NULL, 1, 4, 7)</literal>,
-          and so on. You can insert a row having <literal>NULL</literal>
-          for column <literal>c1</literal> into each of the tables
-          <literal>ts2</literal> and <literal>ts3</literal>:
+      <para>
+        When defining value lists for partitioning, you can (and should)
+        treat <literal>NULL</literal> just as you would any other value.
+        For example, both <literal>VALUES IN (NULL)</literal> and
+        <literal>VALUES IN (1, 4, 7, NULL)</literal> are valid, as are
+        <literal>VALUES IN (1, NULL, 4, 7)</literal>, <literal>VALUES IN
+        (NULL, 1, 4, 7)</literal>, and so on. You can insert a row
+        having <literal>NULL</literal> for column <literal>c1</literal>
+        into each of the tables <literal>ts2</literal> and
+        <literal>ts3</literal>:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>INSERT INTO ts2 VALUES (NULL, 'mothra');</userinput>

@@ -3594,12 +3637,14 @@
 Query OK, 1 row affected (0.00 sec)
 </programlisting>
 
-          By issuing the appropriate query against
-          <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal>,
-          you can determine which partitions were used to store the rows
-          just inserted (we assume, as in the previous examples, that
-          the partitioned tables were created in the
-          <literal>p</literal> database):
+      <para>
+        By issuing the appropriate query against
+        <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal>, you
+        can determine which partitions were used to store the rows just
+        inserted (we assume, as in the previous examples, that the
+        partitioned tables were created in the <literal>p</literal>
+        database):
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH</userinput>

@@ -3619,14 +3664,13 @@
 7 rows in set (0.01 sec)
 </programlisting>
 
-          As shown earlier in this section, you can also verify which
-          partitions were used for storing the rows by deleting these
-          partitions and then performing a
-          <literal role="stmt">SELECT</literal>.
-        </para>
+      <para>
+        As shown earlier in this section, you can also verify which
+        partitions were used for storing the rows by deleting these
+        partitions and then performing a
+        <literal role="stmt">SELECT</literal>.
+      </para>
 
-      </formalpara>
-
       <formalpara>
 
         <title>Handling of <literal>NULL</literal> with <literal>HASH</literal> and

@@ -3644,7 +3688,10 @@
           Suppose that you have a table <literal>th</literal> (also in
           the <literal>p</literal> database) created using the following
           statement:
+        </para>
 
+      </formalpara>
+
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE th (</userinput>
     -&gt;     <userinput>c1 INT,</userinput>

@@ -3655,8 +3702,10 @@
 Query OK, 0 rows affected (0.00 sec)
 </programlisting>
 
-          The partitions belonging to this table can be viewed like
-          this:
+      <para>
+        The partitions belonging to this table can be viewed using the
+        query shown here:
+      </para>
 
 <programlisting>
 mysql&gt; SELECT TABLE_NAME,PARTITION_NAME,TABLE_ROWS,AVG_ROW_LENGTH,DATA_LENGTH

@@ -3671,10 +3720,12 @@
 2 rows in set (0.00 sec)
 </programlisting>
 
-          Note that TABLE_ROWS for each partition is 0. Now insert two
-          rows into <literal>th</literal> whose <literal>c1</literal>
-          column values are <literal>NULL</literal> and 0, and verify
-          that these rows were inserted:
+      <para>
+        Note that <literal>TABLE_ROWS</literal> for each partition is 0.
+        Now insert two rows into <literal>th</literal> whose
+        <literal>c1</literal> column values are <literal>NULL</literal>
+        and 0, and verify that these rows were inserted, as shown here:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>INSERT INTO th VALUES (NULL, 'mothra'), (0, 'gigan');</userinput>

@@ -3691,16 +3742,18 @@
 2 rows in set (0.01 sec)
 </programlisting>
 
-          Recall that for any integer <replaceable>N</replaceable>, the
-          value of <literal>NULL MOD
-          <replaceable>N</replaceable></literal> is always
-          <literal>NULL</literal>. For tables that are partitioned by
-          <literal>HASH</literal> or <literal>KEY</literal>, this result
-          is treated for determining the correct partition as
-          <literal>0</literal>. Checking the
-          <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal>
-          table once again, we can see that both rows were inserted into
-          partition <literal>p0</literal>:
+      <para>
+        Recall that for any integer <replaceable>N</replaceable>, the
+        value of <literal>NULL MOD
+        <replaceable>N</replaceable></literal> is always
+        <literal>NULL</literal>. For tables that are partitioned by
+        <literal>HASH</literal> or <literal>KEY</literal>, this result
+        is treated for determining the correct partition as
+        <literal>0</literal>. Checking the
+        <literal role="is">INFORMATION_SCHEMA.PARTITIONS</literal> table
+        once again, we can see that both rows were inserted into
+        partition <literal>p0</literal>:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT TABLE_NAME, PARTITION_NAME, TABLE_ROWS, AVG_ROW_LENGTH, DATA_LENGTH</userinput>

@@ -3715,15 +3768,14 @@
 2 rows in set (0.00 sec)
 </programlisting>
 
-          If you repeat this example using <literal>PARTITION BY
-          KEY</literal> in place of <literal>PARTITION BY HASH</literal>
-          in the definition of the table, you can verify easily that
-          <literal>NULL</literal> is also treated like 0 for this type
-          of partitioning as well.
-        </para>
+      <para>
+        If you repeat this example using <literal>PARTITION BY
+        KEY</literal> in place of <literal>PARTITION BY HASH</literal>
+        in the definition of the table, you can verify easily that
+        <literal>NULL</literal> is also treated like 0 for this type of
+        partitioning.
+      </para>
 
-      </formalpara>
-
     </section>
 
   </section>

@@ -3879,8 +3931,8 @@
     </important>
 
     <para>
-      Beginning with MySQL 6.0.14, it is possible to delete rows from
-      one or more selected partitions using
+      Beginning with MySQL 6.0.14, it is possible to delete all rows
+      from one or more selected partitions using
       <literal role="stmt" condition="alter-table">ALTER TABLE ...
       TRUNCATE PARTITION</literal>.
     </para>

@@ -3999,9 +4051,10 @@
 </programlisting>
 
       <para>
-        Because of this, you must have the <literal>DROP</literal>
-        privilege for a table before you can execute <literal>ALTER
-        TABLE ... DROP PARTITION</literal> on that table.
+        Because of this, you must have the
+        <literal role="priv">DROP</literal> privilege for a table before
+        you can execute <literal>ALTER TABLE ... DROP
+        PARTITION</literal> on that table.
       </para>
 
       <para>

@@ -4137,6 +4190,7 @@
           high end of the partitions list only. Trying to add a new
           partition in this manner between or before existing partitions
           will result in an error as shown here:
+        </para>
 
 <programlisting>
 mysql&gt; <userinput>ALTER TABLE members</userinput>

@@ -4145,13 +4199,13 @@
 ERROR 1463 (HY000): VALUES LESS THAN value must be strictly &raquo;
    increasing for each partition
 </programlisting>
-        </para>
       </important>
 
       <para>
         In a similar fashion, you can add new partitions to a table that
-        is partitioned by <literal>LIST</literal>. For example, given a
-        table defined like so:
+        is partitioned by <literal>LIST</literal>. Suppose a table
+        <literal>tt</literal> is defined using the following
+        <literal role="stmt">CREATE TABLE</literal> statement:
       </para>
 
 <programlisting>

@@ -4313,7 +4367,7 @@
 
       <para>
         The general syntax for <literal>REORGANIZE PARTITION</literal>
-        is:
+        is shown here:
       </para>
 
 <programlisting>

@@ -4800,18 +4854,11 @@
         </para>
       </note>
 
-      <remark role="note">
-        [js] Commented out following para, pending verification of the
-        statement contained therein.
-      </remark>
-
-<!--
       <para>
         The use of <command>mysqlcheck</command> and
-        <command>myisamchk</command> is also not supported with
-        partitioned tables.
+        <command>myisamchk</command> is not supported with partitioned
+        tables.
       </para>
--->
 
       <para>
         Beginning with MySQL 6.0.14, you can also truncate partitions

@@ -4852,8 +4899,8 @@
 
       <para>
         This section discusses obtaining information about existing
-        partitions, which can be done in a number of ways. These
-        include:
+        partitions, which can be done in a number of ways. Methods of
+        obtaining such information include the following:
       </para>
 
       <itemizedlist>

@@ -4955,7 +5002,7 @@
       </para>
 
       <para>
-        Suppose that you have a table <literal>trb1</literal> defined
+        Suppose that you have a table <literal>trb1</literal> created
         and populated as follows:
       </para>
 

@@ -5152,10 +5199,10 @@
       will be in either of the partitions <literal>p0</literal> or
       <literal>p3</literal>; that is, we need to search only in
       partitions <literal>p1</literal> and <literal>p2</literal> to find
-      matching rows. By doing so, it is possible to expend much more
-      time and effort in finding matching rows than it is to scan all
-      partitions in the table. This <quote>cutting away</quote> of
-      unneeded partitions is known as <firstterm>pruning</firstterm>.
+      matching rows. By doing so, it is possible to expend much less
+      time and effort in finding matching rows than would be required to
+      scan all partitions in the table. This <quote>cutting away</quote>
+      of unneeded partitions is known as <firstterm>pruning</firstterm>.
       When the optimizer can make use of partition pruning in performing
       a query, execution of the query can be an order of magnitude
       faster than the same query against a nonpartitioned table

@@ -5165,7 +5212,7 @@
     <para>
       The query optimizer can perform pruning whenever a
       <literal>WHERE</literal> condition can be reduced to either one of
-      the following:
+      the following two cases:
     </para>
 
     <itemizedlist>

@@ -5407,7 +5454,8 @@
 </programlisting>
 
     <para>
-      Any query such as this one can be pruned:
+      Any query, such as this one, that compares a column value with a
+      constant can be pruned:
     </para>
 
 <programlisting>

@@ -5437,11 +5485,13 @@
       <para>
         This optimization is used only if the range size is smaller than
         the number of partitions. Consider this query:
+      </para>
 
 <programlisting>
 SELECT * FROM t4 WHERE region_code BETWEEN 4 AND 12;
 </programlisting>
 
+      <para>
         The range in the <literal>WHERE</literal> clause covers 9 values
         (4, 5, 6, 7, 8, 9, 10, 11, 12), but <literal>t4</literal> has
         only 8 partitions. This means that the previous query cannot be

@@ -5474,160 +5524,152 @@
 
     <title>Restrictions and Limitations on Partitioning</title>
 
-    <para>
-      This section discusses current restrictions and limitations on
-      MySQL partitioning support, as listed here:
-    </para>
-
     <indexterm>
       <primary>partitioning</primary>
       <secondary>limitations</secondary>
     </indexterm>
 
+    <para>
+      This section discusses current restrictions and limitations on
+      MySQL partitioning support.
+    </para>
+
+    <formalpara>
+
+      <title>Prohibited constructs</title>
+
+      <para>
+        The following constructs are not permitted in partitioning
+        expressions:
+      </para>
+
+    </formalpara>
+
     <itemizedlist>
 
       <listitem>
-        <formalpara>
+        <para>
+          Stored procedures, stored functions, UDFs, or plugins.
+        </para>
+      </listitem>
 
-          <title>Prohibited constructs</title>
+      <listitem>
+        <para>
+          Declared variables or user variables.
+        </para>
+      </listitem>
 
-          <para>
-            The following constructs are not permitted in partitioning
-            expressions:
+    </itemizedlist>
 
-            <itemizedlist>
+    <para>
+      For a list of SQL functions which are permitted in partitioning
+      expressions, see
+      <xref linkend="partitioning-limitations-functions"/>.
+    </para>
 
-              <listitem>
-                <para>
-                  Stored procedures, stored functions, UDFs, or plugins.
-                </para>
-              </listitem>
+    <formalpara>
 
-              <listitem>
-                <para>
-                  Declared variables or user variables.
-                </para>
-              </listitem>
+      <title>Arithmetic and logical operators</title>
 
-            </itemizedlist>
+      <para>
+        <indexterm>
+          <primary>partitioning</primary>
+          <secondary>operators supported in partitioning expressions</secondary>
+        </indexterm>
 
-            For a list of SQL functions which are permitted in
-            partitioning expressions, see
-            <xref linkend="partitioning-limitations-functions"/>.
-          </para>
+        <indexterm>
+          <primary>partitioning</primary>
+          <secondary>operators not permitted in partitioning expressions</secondary>
+        </indexterm>
 
-        </formalpara>
-      </listitem>
+        Use of the arithmetic operators
+        <literal role="op" condition="plus">+</literal>,
+        <literal role="op" condition="minus">-</literal>, and
+        <literal role="op" condition="times">*</literal> is permitted in
+        partitioning expressions. However, the result must be an integer
+        value or <literal>NULL</literal> (except in the case of
+        <literal>[LINEAR] KEY</literal> partitioning, as discussed
+        elswhere in this chapter; see
+        <xref linkend="partitioning-types"/>, for more information).
+      </para>
 
-      <listitem>
-        <formalpara>
+    </formalpara>
 
-          <title>Arithmetic and logical operators</title>
+    <para>
+      Beginning with MySQL 6.0.4, the <literal role="op">DIV</literal>
+      operator is also supported, and the
+      <literal role="op" condition="divide">/</literal> operator is not
+      permitted. (Bug#30188, Bug#33182)
+    </para>
 
-          <para>
-            <indexterm>
-              <primary>partitioning</primary>
-              <secondary>operators supported in partitioning expressions</secondary>
-            </indexterm>
+    <para>
+      The bit operators
+      <literal role="op" condition="bitwise-or">|</literal>,
+      <literal role="op" condition="bitwise-and">&amp;</literal>,
+      <literal role="op" condition="bitwise-xor">^</literal>,
+      <literal role="op" condition="left-shift">&lt;&lt;</literal>,
+      <literal role="op" condition="right-shift">&gt;&gt;</literal>, and
+      <literal role="op" condition="bitwise-invert">~</literal> are not
+      permitted in partitioning expressions.
+    </para>
 
-            <indexterm>
-              <primary>partitioning</primary>
-              <secondary>operators not permitted in partitioning expressions</secondary>
-            </indexterm>
+    <formalpara>
 
-            Use of the arithmetic operators
-            <literal role="op" condition="plus">+</literal>,
-            <literal role="op" condition="minus">-</literal>, and
-            <literal role="op" condition="times">*</literal> is
-            permitted in partitioning expressions. However, the result
-            must be an integer value or <literal>NULL</literal> (except
-            in the case of <literal>[LINEAR] KEY</literal> partitioning,
-            as discussed elswhere in this chapter; see
-            <xref linkend="partitioning-types"/>, for more information).
-          </para>
+      <title>Server SQL mode</title>
 
-        </formalpara>
+      <para>
+        <indexterm>
+          <primary>partitioning</primary>
+          <secondary>and SQL mode</secondary>
+        </indexterm>
 
-        <para>
-          Beginning with MySQL 6.0.4, the
-          <literal role="op">DIV</literal> operator is also supported,
-          and the <literal role="op" condition="divide">/</literal>
-          operator is not permitted. (Bug#30188, Bug#33182)
-        </para>
+        <indexterm>
+          <primary>SQL mode</primary>
+          <secondary>and partitioning</secondary>
+        </indexterm>
 
-        <para>
-          The bit operators
-          <literal role="op" condition="bitwise-or">|</literal>,
-          <literal role="op" condition="bitwise-and">&amp;</literal>,
-          <literal role="op" condition="bitwise-xor">^</literal>,
-          <literal role="op" condition="left-shift">&lt;&lt;</literal>,
-          <literal role="op" condition="right-shift">&gt;&gt;</literal>,
-          and <literal role="op" condition="bitwise-invert">~</literal>
-          are not permitted in partitioning expressions.
-        </para>
-      </listitem>
+        Tables employing user-defined partitioning do not preserve the
+        SQL mode in effect at the time that they were created. As
+        discussed in <xref linkend="server-sql-mode"/>, the results of
+        many MySQL functions and operators may change according to the
+        server SQL mode. Therefore, a change in the SQL mode at any time
+        after the creation of partitioned tables may lead to major
+        changes in the behavior of such tables, and could easily lead to
+        corruption or loss of data. For these reasons, <emphasis>it is
+        strongly recommended that you never change the server SQL mode
+        after creating partitioned tables</emphasis>.
+      </para>
 
-      <listitem>
-        <formalpara>
+    </formalpara>
 
-          <title>Server SQL mode</title>
+    <formalpara>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>and SQL mode</secondary>
-          </indexterm>
+      <title>Examples</title>
 
-          <indexterm>
-            <primary>SQL mode</primary>
-            <secondary>and partitioning</secondary>
-          </indexterm>
+      <para>
+        The following examples illustrate some changes in behavior of
+        partitioned tables due to a change in the server SQL mode:
+      </para>
 
-          <para>
-            Tables employing user-defined partitioning do not preserve
-            the SQL mode in effect at the time that they were created.
-            As discussed in <xref linkend="server-sql-mode"/>, the
-            results of many MySQL functions and operators may change
-            according to the server SQL mode. Therefore, a change in the
-            SQL mode at any time after the creation of partitioned
-            tables may lead to major changes in the behavior of such
-            tables, and could easily lead to corruption or loss of data.
-            For these reasons, <emphasis>it is strongly recommended that
-            you never change the server SQL mode after creating
-            partitioned tables</emphasis>.
-          </para>
+    </formalpara>
 
-        </formalpara>
+    <orderedlist>
 
+      <listitem>
         <formalpara>
 
-          <title>Examples</title>
+          <title>Error handling</title>
 
           <para>
-            The following examples illustrate some changes in behavior
-            of partitioned tables due to a change in the server SQL
-            mode:
+            Suppose that you create a partitioned table whose
+            partitioning expression is one such as
+            <literal><replaceable>column</replaceable> DIV 0</literal>
+            or <literal><replaceable>column</replaceable> MOD
+            0</literal>, as shown here:
           </para>
 
         </formalpara>
 
-        <orderedlist>
-
-          <listitem>
-            <formalpara>
-
-              <title>Error handling</title>
-
-              <para>
-                Suppose that you create a partitioned table whose
-                partitioning expression is one such as
-                <literal><replaceable>column</replaceable> DIV
-                0</literal> or
-                <literal><replaceable>column</replaceable> MOD
-                0</literal>, as shown here:
-              </para>
-
-            </formalpara>
-
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE tn (c1 INT)</userinput>
     -&gt;     <userinput>PARTITION BY LIST(1 DIV c1) (</userinput>

@@ -5637,11 +5679,11 @@
 Query OK, 0 rows affected (0.05 sec)
 </programlisting>
 
-            <para>
-              The default behavior for MySQL is to return
-              <literal>NULL</literal> for the result of a division by
-              zero, without producing any errors:
-            </para>
+        <para>
+          The default behavior for MySQL is to return
+          <literal>NULL</literal> for the result of a division by zero,
+          without producing any errors:
+        </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT @@sql_mode;</userinput>

@@ -5658,12 +5700,12 @@
 Records: 3  Duplicates: 0  Warnings: 0
 </programlisting>
 
-            <para>
-              However, changing the server SQL mode to treat division by
-              zero as an error and to enforce strict error handling
-              causes the same <literal role="stmt">INSERT</literal>
-              statement to fail, as shown here:
-            </para>
+        <para>
+          However, changing the server SQL mode to treat division by
+          zero as an error and to enforce strict error handling causes
+          the same <literal role="stmt">INSERT</literal> statement to
+          fail, as shown here:
+        </para>
 
 <programlisting>
 mysql&gt; <userinput>SET sql_mode='STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO';</userinput>

@@ -5672,23 +5714,23 @@
 mysql&gt; <userinput>INSERT INTO tn VALUES (NULL), (0), (1);</userinput>
 <errortext>ERROR 1365 (22012): Division by 0</errortext>
 </programlisting>
-          </listitem>
+      </listitem>
 
-          <listitem>
-            <formalpara>
+      <listitem>
+        <formalpara>
 
-              <title>Table accessibility</title>
+          <title>Table accessibility</title>
 
-              <para>
-                Sometimes a change in the server SQL mode can make
-                partitioned tables unusable. The following
-                <literal role="stmt">CREATE TABLE</literal> statement
-                can be executed successfully only if the
-                <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-                mode is in effect:
-              </para>
+          <para>
+            Sometimes a change in the server SQL mode can make
+            partitioned tables unusable. The following
+            <literal role="stmt">CREATE TABLE</literal> statement can be
+            executed successfully only if the
+            <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
+            mode is in effect:
+          </para>
 
-            </formalpara>
+        </formalpara>
 
 <programlisting>
 mysql&gt; <userinput>SELECT @@sql_mode;</userinput>

@@ -5731,12 +5773,12 @@
 Query OK, 0 rows affected (0.05 sec)
 </programlisting>
 
-            <para>
-              If you remove the
-              <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
-              server SQL mode after creating <literal>tu</literal>, you
-              may no longer be able to access this table:
-            </para>
+        <para>
+          If you remove the
+          <literal role="sqlmode">NO_UNSIGNED_SUBTRACTION</literal>
+          server SQL mode after creating <literal>tu</literal>, you may
+          no longer be able to access this table:
+        </para>
 
 <programlisting>
 mysql&gt; <userinput>SET sql_mode='';</userinput>

@@ -5747,396 +5789,371 @@
 mysql&gt; <userinput>INSERT INTO tu VALUES (20);</userinput>
 <errortext>ERROR 1563 (HY000): Partition constant is out of partition function domain</errortext>
 </programlisting>
-          </listitem>
+      </listitem>
 
-        </orderedlist>
+    </orderedlist>
 
+    <para>
+      Server SQL modes also impact replication of partitioned tables.
+      Differing SQL modes on master and slave can lead to partitioning
+      expressions being evaluated differently; this can cause the
+      distribution of data among partitions to be different in the
+      master&apos;s and slave&apos;s copies of a given table, and may
+      even cause inserts into partitioned tables that succeed on the
+      master to fail on the slave. For best results, you should always
+      use the same server SQL mode on the master and on the slave.
+    </para>
+
+    <formalpara>
+
+      <title>Performance considerations</title>
+
+      <para>
+        Some affects of partitioning operations on performance are given
+        in the following list:
+      </para>
+
+    </formalpara>
+
+    <itemizedlist>
+
+      <listitem>
+        <formalpara id="partitioning-limitations-file-system-ops">
+
+          <title>File system operations</title>
+
+          <para>
+            Partitioning and repartitioning operations (such as
+            <literal role="stmt">ALTER TABLE</literal> with
+            <literal>PARTITION BY ...</literal>, <literal>REORGANIZE
+            PARTITIONS</literal>, or <literal>REMOVE
+            PARTITIONING</literal>) depend on file system operations for
+            their implementation. This means that the speed of these
+            operations is affected by such factors as file system type
+            and characteristics, disk speed, swap space, file handling
+            efficiency of the operating system, and MySQL server options
+            and variables that relate to file handling. In particular,
+            you should make sure that
+            <literal role="sysvar">large_files_support</literal> is
+            enabled and that
+            <literal role="sysvar">open_files_limit</literal> is set
+            properly. For partitioned tables using the
+            <literal>MyISAM</literal> storage engine, increasing
+            <literal role="sysvar">myisam_max_sort_file_size</literal>
+            may improve performance; partitioning and repartitioning
+            operations involving <literal>InnoDB</literal> tables may be
+            made more efficient by enabling
+            <literal role="sysvar">innodb_file_per_table</literal>.
+          </para>
+
+        </formalpara>
+
         <para>
-          Server SQL modes also impact replication of partitioned
-          tables. Differing SQL modes on master and slave can lead to
-          partitioning expressions being evaluated differently; this can
-          cause the distribution of data among partitions to be
-          different in the master&apos;s and slave&apos;s copies of a
-          given table, and may even cause inserts into partitioned
-          tables that succeed on the master to fail on the slave. For
-          best results, you should always use the same server SQL mode
-          on the master and on the slave.
+          See also
+          <xref linkend="partitioning-limitations-max-partitions"/>.
         </para>
       </listitem>
 
       <listitem>
         <formalpara>
 
-          <title>Performance considerations</title>
+          <title>Table locks</title>
 
           <para>
-            Some affects of partitioning operations on performance are
-            given in the following list:
+            The process executing a partitioning operation on a table
+            takes a write lock on the table. Reads from such tables are
+            relatively unaffected; pending
+            <literal role="stmt">INSERT</literal> and
+            <literal role="stmt">UPDATE</literal> operations are
+            performed as soon as the partitioning operation has
+            completed.
           </para>
 
         </formalpara>
+      </listitem>
 
-        <itemizedlist>
+      <listitem>
+        <formalpara>
 
-          <listitem>
-            <formalpara id="partitioning-limitations-file-system-ops">
+          <title>Storage engine</title>
 
-              <title>File system operations</title>
+          <para>
+            Partitioning operations, queries, and update operations
+            generally tend to be faster with <literal>MyISAM</literal>
+            tables than with <literal>InnoDB</literal> tables.
+          </para>
 
-              <para>
-                Partitioning and repartitioning operations (such as
-                <literal role="stmt">ALTER TABLE</literal> with
-                <literal>PARTITION BY ...</literal>, <literal>REORGANIZE
-                PARTITIONS</literal>, or <literal>REMOVE
-                PARTITIONING</literal>) depend on file system operations
-                for their implementation. This means that the speed of
-                these operations is affected by such factors as file
-                system type and characteristics, disk speed, swap space,
-                file handling efficiency of the operating system, and
-                MySQL server options and variables that relate to file
-                handling. In particular, you should make sure that
-                <literal role="sysvar">large_files_support</literal> is
-                enabled and that
-                <literal role="sysvar">open_files_limit</literal> is set
-                properly. For partitioned tables using the
-                <literal>MyISAM</literal> storage engine, increasing
-                <literal role="sysvar">myisam_max_sort_file_size</literal>
-                may improve performance; partitioning and repartitioning
-                operations involving <literal>InnoDB</literal> tables
-                may be made more efficient by enabling
-                <literal role="sysvar">innodb_file_per_table</literal>.
-              </para>
+        </formalpara>
+      </listitem>
 
-            </formalpara>
+      <listitem>
+        <formalpara>
 
-            <para>
-              See also
-              <xref linkend="partitioning-limitations-max-partitions"/>.
-            </para>
-          </listitem>
+          <title>Use of indexes and partition pruning</title>
 
-          <listitem>
-            <formalpara>
+          <para>
+            As with nonpartitioned tables, proper use of indexes can
+            speed up queries on partitioned tables significantly. In
+            addition, designing partitioned tables and queries on these
+            tables to take advantage of <firstterm>partition
+            pruning</firstterm> can improve performance dramatically.
+            See <xref linkend="partitioning-pruning"/>, for more
+            information.
+          </para>
 
-              <title>Table locks</title>
+        </formalpara>
+      </listitem>
 
-              <para>
-                The process executing a partitioning operation on a
-                table takes a write lock on the table. Reads from such
-                tables are relatively unaffected; pending
-                <literal role="stmt">INSERT</literal> and
-                <literal role="stmt">UPDATE</literal> operations are
-                performed as soon as the partitioning operation has
-                completed.
-              </para>
+      <listitem>
+        <formalpara>
 
-            </formalpara>
-          </listitem>
+          <title>Performance with <literal role="stmt">LOAD DATA</literal></title>
 
-          <listitem>
-            <formalpara>
+          <para>
+            Prior to MySQL 6.0.4, <literal role="stmt">LOAD
+            DATA</literal> performed very poorly when importing into
+            partitioned tables. The statement now uses buffering to
+            improve performance; however, the buffer uses 130 KB memory
+            per partition to achieve this. (Bug#26527)
+          </para>
 
-              <title>Storage engine</title>
+        </formalpara>
+      </listitem>
 
-              <para>
-                Partitioning operations, queries, and update operations
-                generally tend to be faster with
-                <literal>MyISAM</literal> tables than with
-                <literal>InnoDB</literal> or
-                <literal role="se">NDB</literal> tables.
-              </para>
+    </itemizedlist>
 
-            </formalpara>
-          </listitem>
+    <formalpara id="partitioning-limitations-max-partitions">
 
-          <listitem>
-            <formalpara>
+      <title>Maximum number of partitions</title>
 
-              <title>Use of indexes and partition pruning</title>
+      <indexterm>
+        <primary>Partitioning</primary>
+        <secondary>maximum number of partitions</secondary>
+      </indexterm>
 
-              <para>
-                As with nonpartitioned tables, proper use of indexes can
-                speed up queries on partitioned tables significantly. In
-                addition, designing partitioned tables and queries on
-                these tables to take advantage of <firstterm>partition
-                pruning</firstterm> can improve performance
-                dramatically. See
-                <xref linkend="partitioning-pruning"/>, for more
-                information.
-              </para>
+      <indexterm>
+        <primary>Out of resources error</primary>
+        <secondary>and partitioned tables</secondary>
+      </indexterm>
 
-            </formalpara>
-          </listitem>
+      <para>
+        The maximum possible number of partitions for a given table is
+        1024. This includes subpartitions.
+      </para>
 
-          <listitem>
-            <formalpara>
+    </formalpara>
 
-              <title>Performance with <literal role="stmt">LOAD DATA</literal></title>
+    <para>
+      If, when creating tables with a large number of partitions (but
+      less than the maximum), you encounter an error message such as
+      <errortext>Got error ... from storage engine: Out of resources
+      when opening file</errortext>, you may be able to address the
+      issue by increasing the value of the
+      <literal role="sysvar">open_files_limit</literal> system variable.
+      However, this is dependent on the operating system, and may not be
+      possible or advisable on all platforms; see
+      <xref linkend="not-enough-file-handles"/>, for more information.
+      In some cases, using large numbers (hundreds) of partitions may
+      also not be advisable due to other concerns, so using more
+      partitions does not automatically lead to better results.
+    </para>
 
-              <para>
-                Prior to MySQL 6.0.4, <literal role="stmt">LOAD
-                DATA</literal> performed very poorly when importing into
-                partitioned tables. The statement now uses buffering to
-                improve performance; however, the buffer uses 130 KB
-                memory per partition to achieve this. (Bug#26527)
-              </para>
+    <para>
+      See also
+      <xref linkend="partitioning-limitations-file-system-ops"/>.
+    </para>
 
-            </formalpara>
-          </listitem>
+    <formalpara>
 
-        </itemizedlist>
-      </listitem>
+      <title>Per-partition key caches</title>
 
-      <listitem>
-        <formalpara id="partitioning-limitations-max-partitions">
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>and key cache</secondary>
+      </indexterm>
 
-          <title>Maximum number of partitions</title>
+      <indexterm>
+        <primary>CACHE INDEX</primary>
+        <secondary>and partitioning</secondary>
+      </indexterm>
 
-          <indexterm>
-            <primary>Partitioning</primary>
-            <secondary>maximum number of partitions</secondary>
-          </indexterm>
+      <indexterm>
+        <primary>LOAD INDEX INTO CACHE</primary>
+        <secondary>and partitioning</secondary>
+      </indexterm>
 
-          <indexterm>
-            <primary>Out of resources error</primary>
-            <secondary>and partitioned tables</secondary>
-          </indexterm>
+      <para>
+        Beginning with MySQL 6.0.14, key caches are supported for
+        partitioned <literal role="se">MyISAM</literal> tables, using
+        the <literal role="stmt">CACHE INDEX</literal> and
+        <literal role="stmt" condition="load-index">LOAD INDEX INTO
+        CACHE</literal> statements. Key caches may be defined for one,
+        several, or all partitions, and indexes for one, several, or all
+        partitions may be preloaded into key caches.
+      </para>
 
-          <para>
-            The maximum possible number of partitions for a given table
-            is 1024. This includes subpartitions.
-          </para>
+    </formalpara>
 
-        </formalpara>
+    <formalpara>
 
-        <para>
-          If, when creating tables with a large number of partitions
-          (but less than the maximum), you encounter an error message
-          such as <errortext>Got error ... from storage engine: Out of
-          resources when opening file</errortext>, you may be able to
-          address the issue by increasing the value of the
-          <literal role="sysvar">open_files_limit</literal> system
-          variable. However, this is dependent on the operating system,
-          and may not be possible or advisable on all platforms; see
-          <xref linkend="not-enough-file-handles"/>, for more
-          information. In some cases, using large numbers (hundreds) of
-          partitions may also not be advisable due to other concerns, so
-          using more partitions does not automatically lead to better
-          results.
-        </para>
+      <title>Foreign keys not supported</title>
 
-        <para>
-          See also
-          <xref linkend="partitioning-limitations-file-system-ops"/>.
-        </para>
-      </listitem>
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>and foreign keys</secondary>
+      </indexterm>
 
-      <listitem>
-        <formalpara>
+      <para>
+        Partitioned tables do not support foreign keys. More
+        specifically, this means that the following two statements are
+        true:
+      </para>
 
-          <title>Per-partition key caches</title>
+    </formalpara>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>and key cache</secondary>
-          </indexterm>
+    <orderedlist>
 
-          <indexterm>
-            <primary>CACHE INDEX</primary>
-            <secondary>and partitioning</secondary>
-          </indexterm>
-
-          <indexterm>
-            <primary>LOAD INDEX INTO CACHE</primary>
-            <secondary>and partitioning</secondary>
-          </indexterm>
-
-          <para>
-            Beginning with MySQL 6.0.14, key caches are supported for
-            partitioned <literal role="se">MyISAM</literal> tables,
-            using the <literal role="stmt">CACHE INDEX</literal> and
-            <literal role="stmt" condition="load-index">LOAD INDEX INTO
-            CACHE</literal> statements. Key caches may be defined for
-            one, several, or all partitions, and indexes for one,
-            several, or all partitions may be preloaded into key caches.
-          </para>
-
-        </formalpara>
+      <listitem>
+        <para>
+          Definitions of tables employing user-defined partitioning may
+          not contain foreign key references to other tables.
+        </para>
       </listitem>
 
       <listitem>
-        <formalpara>
+        <para>
+          No table definition may contain a foreign key reference to a
+          partitioned table.
+        </para>
+      </listitem>
 
-          <title>Foreign keys not supported</title>
+    </orderedlist>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>and foreign keys</secondary>
-          </indexterm>
+    <para>
+      The scope of these restrictions includes tables that use the
+      <literal>InnoDB</literal> storage engine.
+    </para>
 
-          <para>
-            Partitioned tables do not support foreign keys. This means
-            that:
+    <formalpara>
 
-            <orderedlist>
+      <title><literal>ALTER TABLE ... ORDER BY</literal></title>
 
-              <listitem>
-                <para>
-                  Definitions of tables employing user-defined
-                  partitioning may not contain foreign key references to
-                  other tables.
-                </para>
-              </listitem>
+      <para>
+        An <literal>ALTER TABLE ... ORDER BY
+        <replaceable>column</replaceable></literal> statement run
+        against a partitioned table causes ordering of rows only within
+        each partition.
+      </para>
 
-              <listitem>
-                <para>
-                  No table definition may contain a foreign key
-                  reference to a partitioned table.
-                </para>
-              </listitem>
+    </formalpara>
 
-            </orderedlist>
+    <formalpara>
 
-            The scope of these restrictions includes tables that use the
-            <literal>InnoDB</literal> storage engine.
-          </para>
+      <title>FULLTEXT indexes</title>
 
-        </formalpara>
-      </listitem>
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>and FULLTEXT indexes</secondary>
+      </indexterm>
 
-      <listitem>
-        <formalpara>
+      <para>
+        Partitioned tables do not support <literal>FULLTEXT</literal>
+        indexes. This includes partitioned tables employing the
+        <literal>MyISAM</literal> storage engine.
+      </para>
 
-          <title><literal>ALTER TABLE ... ORDER BY</literal></title>
+    </formalpara>
 
-          <para>
-            An <literal>ALTER TABLE ... ORDER BY
-            <replaceable>column</replaceable></literal> statement run
-            against a partitioned table causes ordering of rows only
-            within each partition.
-          </para>
+    <formalpara>
 
-        </formalpara>
-      </listitem>
+      <title>Spatial columns</title>
 
-      <listitem>
-        <formalpara>
+      <para>
+        Columns with spatial data types such as <literal>POINT</literal>
+        or <literal>GEOMETRY</literal> cannot be used in partitioned
+        tables.
+      </para>
 
-          <title>FULLTEXT indexes</title>
+    </formalpara>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>and FULLTEXT indexes</secondary>
-          </indexterm>
+    <formalpara>
 
-          <para>
-            Partitioned tables do not support
-            <literal>FULLTEXT</literal> indexes. This includes
-            partitioned tables employing the <literal>MyISAM</literal>
-            storage engine.
-          </para>
+      <title>Temporary tables</title>
 
-        </formalpara>
-      </listitem>
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>and temporary tables</secondary>
+      </indexterm>
 
-      <listitem>
-        <formalpara>
+      <para>
+        Temporary tables cannot be partitioned. (Bug#17497)
+      </para>
 
-          <title>Spatial columns</title>
+    </formalpara>
 
-          <para>
-            Columns with spatial data types such as
-            <literal>POINT</literal> or <literal>GEOMETRY</literal>
-            cannot be used in partitioned tables.
-          </para>
+    <formalpara>
 
-        </formalpara>
-      </listitem>
+      <title>Log tables</title>
 
-      <listitem>
-        <formalpara>
+      <para>
+        It is not possible to partition the log tables; an
+        <literal>ALTER TABLE ... PARTITION BY ...</literal> statement on
+        such a table fails with an error.
+      </para>
 
-          <title>Temporary tables</title>
+    </formalpara>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>and temporary tables</secondary>
-          </indexterm>
+    <formalpara>
 
-          <para>
-            Temporary tables cannot be partitioned. (Bug#17497)
-          </para>
+      <title>Data type of partitioning key</title>
 
-        </formalpara>
-      </listitem>
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>data type of partitioning key</secondary>
+      </indexterm>
 
-      <listitem>
-        <formalpara>
+      <para>
+        A partitioning key must be either an integer column or an
+        expression that resolves to an integer. The column or expression
+        value may also be <literal>NULL</literal>. (See
+        <xref linkend="partitioning-handling-nulls"/>.)
+      </para>
 
-          <title>Log tables</title>
+    </formalpara>
 
-          <para>
-            It is not possible to partition the log tables; an
-            <literal>ALTER TABLE ... PARTITION BY ...</literal>
-            statement on such a table fails with an error. (Bug#27816)
-          </para>
+    <para>
+      There are two exceptions to this restriction:
+    </para>
 
-        </formalpara>
-      </listitem>
+    <orderedlist>
 
       <listitem>
-        <formalpara>
-
-          <title>Data type of partitioning key</title>
-
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>data type of partitioning key</secondary>
-          </indexterm>
-
-          <para>
-            A partitioning key must be either an integer column or an
-            expression that resolves to an integer. The column or
-            expression value may also be <literal>NULL</literal>. (See
-            <xref linkend="partitioning-handling-nulls"/>.)
-          </para>
-
-        </formalpara>
-
         <para>
-          There are two exceptions to this restriction:
+          When partitioning by [<literal>LINEAR</literal>]
+          <literal>KEY</literal>, it is possible to use columns of other
+          types as partitioning keys, because MySQL's internal
+          key-hashing functions produce the correct data type from these
+          types. For example, the following <literal role="stmt">CREATE
+          TABLE</literal> statement is valid:
         </para>
 
-        <orderedlist>
-
-          <listitem>
-            <para>
-              When partitioning by [<literal>LINEAR</literal>]
-              <literal>KEY</literal>, it is possible to use columns of
-              other types as partitioning keys, because MySQL's internal
-              key-hashing functions produce the correct data type from
-              these types. For example, the following
-              <literal role="stmt">CREATE TABLE</literal> statement is
-              valid:
-            </para>
-
 <programlisting>
 CREATE TABLE tkc (c1 CHAR)
 PARTITION BY KEY(c1)
 PARTITIONS 4;
 </programlisting>
-          </listitem>
+      </listitem>
 
-          <listitem>
-            <para>
-              When partitioning by <literal>RANGE COLUMNS</literal> or
-              <literal>LIST COLUMNS</literal> (MySQL 6.0.14 and later),
-              it is possible to use string,
-              <literal role="type">DATE</literal>, and
-              <literal role="type">DATETIME</literal> columns. For
-              example, each of the following <literal role="stmt">CREATE
-              TABLE</literal> statements is valid:
-            </para>
+      <listitem>
+        <para>
+          When partitioning by <literal>RANGE COLUMNS</literal> or
+          <literal>LIST COLUMNS</literal> (MySQL 6.0.14 and later), it
+          is possible to use string,
+          <literal role="type">DATE</literal>, and
+          <literal role="type">DATETIME</literal> columns. For example,
+          each of the following <literal role="stmt">CREATE
+          TABLE</literal> statements is valid:
+        </para>
 
 <programlisting>
 CREATE TABLE rc (c1 INT, c2 DATE)

@@ -6155,75 +6172,68 @@
     PARTITION p2 VALUES IN('c', 'f', 'i', 'l', 'o', 'r', 'u', 'x', NULL)
 );
 </programlisting>
-          </listitem>
+      </listitem>
 
-        </orderedlist>
+    </orderedlist>
 
-        <para>
-          Neither of the preceding exceptions applies to
-          <literal role="type">BLOB</literal> or
-          <literal role="type">TEXT</literal> column types.
-        </para>
-      </listitem>
+    <para>
+      Neither of the preceding exceptions applies to
+      <literal role="type">BLOB</literal> or
+      <literal role="type">TEXT</literal> column types.
+    </para>
 
-      <listitem>
-        <formalpara>
+    <formalpara>
 
-          <title>Subqueries</title>
+      <title>Subqueries</title>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>and subqueries</secondary>
-          </indexterm>
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>and subqueries</secondary>
+      </indexterm>
 
-          <para>
-            A partitioning key may not be a subquery, even if that
-            subquery resolves to an integer value or
-            <literal>NULL</literal>.
-          </para>
+      <para>
+        A partitioning key may not be a subquery, even if that subquery
+        resolves to an integer value or <literal>NULL</literal>.
+      </para>
 
-        </formalpara>
-      </listitem>
+    </formalpara>
 
-      <listitem>
-        <formalpara id="partitioning-limitations-subpartitions">
+    <formalpara id="partitioning-limitations-subpartitions">
 
-          <title>Issues with subpartitions</title>
+      <title>Issues with subpartitions</title>
 
-          <indexterm>
-            <primary>partitioning</primary>
-            <secondary>subpartitioning</secondary>
-          </indexterm>
+      <indexterm>
+        <primary>partitioning</primary>
+        <secondary>subpartitioning</secondary>
+      </indexterm>
 
-          <indexterm>
-            <primary>subpartitions</primary>
-            <secondary>known issues</secondary>
-          </indexterm>
+      <indexterm>
+        <primary>subpartitions</primary>
+        <secondary>known issues</secondary>
+      </indexterm>
 
-          <para>
-            Subpartitions must use <literal>HASH</literal> or
-            <literal>KEY</literal> partitioning. Only
-            <literal>RANGE</literal> and <literal>LIST</literal>
-            partitions may be subpartitioned; <literal>HASH</literal>
-            and <literal>KEY</literal> partitions cannot be
-            subpartitioned.
-          </para>
+      <para>
+        Subpartitions must use <literal>HASH</literal> or
+        <literal>KEY</literal> partitioning. Only
+        <literal>RANGE</literal> and <literal>LIST</literal> partitions
+        may be subpartitioned; <literal>HASH</literal> and
+        <literal>KEY</literal> partitions cannot be subpartitioned.
+      </para>
 
-        </formalpara>
+    </formalpara>
 
-        <para>
-          <indexterm>
-            <primary>SUBPARTITION BY KEY</primary>
-            <secondary>known issues</secondary>
-          </indexterm>
+    <para>
+      <indexterm>
+        <primary>SUBPARTITION BY KEY</primary>
+        <secondary>known issues</secondary>
+      </indexterm>
 
-          Currently, <literal>SUBPARTITION BY KEY</literal> requires
-          that the subpartitioning column or columns be specified
-          explicitly, unlike the case with <literal>PARTITION BY
-          KEY</literal>, where it can be omitted (in which case the
-          table&apos;s primary key column is used by default). Consider
-          table created by this statement:
-        </para>
+      Currently, <literal>SUBPARTITION BY KEY</literal> requires that
+      the subpartitioning column or columns be specified explicitly,
+      unlike the case with <literal>PARTITION BY KEY</literal>, where it
+      can be omitted (in which case the table&apos;s primary key column
+      is used by default). Consider the table created by this statement:
+    </para>
 
 <programlisting>
 CREATE TABLE ts (

@@ -6232,10 +6242,10 @@
 );
 </programlisting>
 
-        <para>
-          You can create a table having the same columns, partitioned by
-          <literal>KEY</literal>, using a statement such as this one:
-        </para>
+    <para>
+      You can create a table having the same columns, partitioned by
+      <literal>KEY</literal>, using a statement such as this one:
+    </para>
 
 <programlisting>
 CREATE TABLE ts (

@@ -6246,11 +6256,11 @@
 PARTITIONS 4;
         </programlisting>
 
-        <para>
-          The previous statement is treated as though it had been
-          written like this, with the table&apos;s primary key column
-          used as the partitioning column:
-        </para>
+    <para>
+      The previous statement is treated as though it had been written
+      like this, with the table&apos;s primary key column used as the
+      partitioning column:
+    </para>
 
 <programlisting>
 CREATE TABLE ts (

@@ -6261,12 +6271,12 @@
 PARTITIONS 4;
         </programlisting>
 
-        <para>
-          However, the following statement that attempts to create a
-          subpartitioned table using the default column as the
-          subpartitioning column fails, and the column must be specified
-          for the statement to succeed, as shown here:
-        </para>
+    <para>
+      However, the following statement that attempts to create a
+      subpartitioned table using the default column as the
+      subpartitioning column fails, and the column must be specified for
+      the statement to succeed, as shown here:
+    </para>
 
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE ts (</userinput>

@@ -6297,93 +6307,81 @@
 Query OK, 0 rows affected (0.07 sec)
 </programlisting>
 
-        <para>
-          This is a known issue, which we are currently working to
-          address (Bug#51470).
-        </para>
-      </listitem>
+    <para>
+      This is a known issue (see Bug#51470).
+    </para>
 
-      <listitem>
-        <formalpara>
+    <formalpara>
 
-          <title><literal>DELAYED</literal> option not supported</title>
+      <title><literal>DELAYED</literal> option not supported</title>
 
-          <para>
-            Use of <literal role="stmt">INSERT DELAYED</literal> to
-            insert rows into a partitioned table is not supported.
-            Beginning with MySQL 6.0.4, attempting to do so fails with
-            an error. (Bug#31210)
-          </para>
+      <para>
+        Use of <literal role="stmt">INSERT DELAYED</literal> to insert
+        rows into a partitioned table is not supported. Beginning with
+        MySQL 6.0.4, attempting to do so fails with an error.
+        (Bug#31210)
+      </para>
 
-        </formalpara>
-      </listitem>
+    </formalpara>
 
-      <listitem>
-        <formalpara>
+    <formalpara>
 
-          <title><literal>DATA DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
-            options</title>
+      <title><literal>DATA DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+        options</title>
 
-          <para>
-            <literal>DATA DIRECTORY</literal> and <literal>INDEX
-            DIRECTORY</literal> are subject to the following
-            restrictions when used with partitioned tables:
+      <para>
+        <literal>DATA DIRECTORY</literal> and <literal>INDEX
+        DIRECTORY</literal> are subject to the following restrictions
+        when used with partitioned tables:
+      </para>
 
-            <itemizedlist>
+    </formalpara>
 
-              <listitem>
-                <para>
-                  Beginning with MySQL 6.0.4, table-level <literal>DATA
-                  DIRECTORY</literal> and <literal>INDEX
-                  DIRECTORY</literal> options are ignored. (Bug#32091)
-                </para>
-              </listitem>
+    <itemizedlist>
 
-              <listitem>
-                <para>
-                  On Windows, the <literal>DATA DIRECTORY</literal> and
-                  <literal>INDEX DIRECTORY</literal> options are not
-                  supported for individual partitions or subpartitions
-                  (Bug#30459).
-                </para>
-              </listitem>
-
-            </itemizedlist>
-          </para>
-
-        </formalpara>
+      <listitem>
+        <para>
+          Beginning with MySQL 6.0.4, table-level <literal>DATA
+          DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
+          options are ignored (see Bug#32091).
+        </para>
       </listitem>
 
       <listitem>
-        <formalpara>
-
-          <title>Repairing and rebuilding partitioned tables</title>
-
-          <para>
-            The statements <literal role="stmt">CHECK TABLE</literal>,
-            <literal role="stmt">OPTIMIZE TABLE</literal>,
-            <literal role="stmt">ANALYZE TABLE</literal>, and
-            <literal role="stmt">REPAIR TABLE</literal> are supported
-            for partitioned tables beginning with MySQL 6.0.6. (See
-            Bug#20129.) <command>mysqlcheck</command> and
-            <command>myisamchk</command> are not supported with
-            partitioned tables.
-          </para>
-
-        </formalpara>
-
         <para>
-          In addition, you can use <literal>ALTER TABLE ... REBUILD
-          PARTITION</literal> to rebuild one or more partitions of a
-          partitioned table; <literal>ALTER TABLE ... REORGANIZE
-          PARTITION</literal> also causes partitions to be rebuilt. See
-          <xref linkend="alter-table"/>, for more information about
-          these two statements.
+          On Windows, the <literal>DATA DIRECTORY</literal> and
+          <literal>INDEX DIRECTORY</literal> options are not supported
+          for individual partitions or subpartitions (Bug#30459).
         </para>
       </listitem>
 
     </itemizedlist>
 
+    <formalpara>
+
+      <title>Repairing and rebuilding partitioned tables</title>
+
+      <para>
+        The statements <literal role="stmt">CHECK TABLE</literal>,
+        <literal role="stmt">OPTIMIZE TABLE</literal>,
+        <literal role="stmt">ANALYZE TABLE</literal>, and
+        <literal role="stmt">REPAIR TABLE</literal> are supported for
+        partitioned tables beginning with MySQL 6.0.6. (See Bug#20129.)
+        <command>mysqlcheck</command> and <command>myisamchk</command>
+        are not supported with partitioned tables.
+      </para>
+
+    </formalpara>
+
+    <para>
+      In addition, you can use <literal>ALTER TABLE ... REBUILD
+      PARTITION</literal> to rebuild one or more partitions of a
+      partitioned table; <literal>ALTER TABLE ... REORGANIZE
+      PARTITION</literal> also causes partitions to be rebuilt. See
+      <xref linkend="alter-table"/>, for more information about these
+      two statements.
+    </para>
+
     <section id="partitioning-limitations-partitioning-keys-unique-keys">
 
       <title>Partitioning Keys, Primary Keys, and Unique Keys</title>

@@ -6734,11 +6732,6 @@
         altogether.
       </para>
 
-      <para>
-        We are working to remove this limitation in a future MySQL
-        release series.
-      </para>
-
     </section>
 
     <section id="partitioning-limitations-storage-engines">

@@ -6775,8 +6768,7 @@
         <para>
           Partitioning of <literal>FEDERATED</literal> tables is not
           supported; it is not possible to create partitioned
-          <literal>FEDERATED</literal> tables. We are working to remove
-          this limitation in a future MySQL release.
+          <literal>FEDERATED</literal> tables.
         </para>
 
       </formalpara>

@@ -6814,31 +6806,28 @@
           the table as a whole. In addition, if one does not specify an
           engine on the table level, then one must do either of the
           following when creating or altering a partitioned table:
+        </para>
 
-          <itemizedlist>
+      </formalpara>
 
-            <listitem>
-              <para>
-                Do <emphasis>not</emphasis> specify any engine for
-                <emphasis>any</emphasis> partition or subpartition
-              </para>
-            </listitem>
+      <itemizedlist>
 
-            <listitem>
-              <para>
-                Specify the engine for <emphasis>all</emphasis>
-                partitions or subpartitions
-              </para>
-            </listitem>
+        <listitem>
+          <para>
+            Do <emphasis>not</emphasis> specify any engine for
+            <emphasis>any</emphasis> partition or subpartition
+          </para>
+        </listitem>
 
-          </itemizedlist>
+        <listitem>
+          <para>
+            Specify the engine for <emphasis>all</emphasis> partitions
+            or subpartitions
+          </para>
+        </listitem>
 
-          We are working to remove this limitation in a future MySQL
-          release.
-        </para>
+      </itemizedlist>
 
-      </formalpara>
-
     </section>
 
     <section id="partitioning-limitations-functions">

@@ -6916,15 +6905,13 @@
         </tgroup>
       </informaltable>
 
-      <note>
-        <para>
-          In MySQL &current-series;, partition pruning is supported only
-          for the <literal role="func">TO_DAYS()</literal>,
-          <literal role="func">TO_SECONDS()</literal>, and
-          <literal role="func">YEAR()</literal> functions. See
-          <xref linkend="partitioning-pruning"/>, for more information.
-        </para>
-      </note>
+      <para>
+        In MySQL &current-series;, partition pruning is supported only
+        for the <literal role="func">TO_DAYS()</literal>,
+        <literal role="func">TO_SECONDS()</literal>, and
+        <literal role="func">YEAR()</literal> functions. See
+        <xref linkend="partitioning-pruning"/>, for more information.
+      </para>
 
       <formalpara id="partitioning-limitations-ceiling-floor">
 

@@ -6936,7 +6923,10 @@
           passed an integer argument. This means, for example, that the
           following <literal role="stmt">CREATE TABLE</literal>
           statement fails with an error, as shown here:
+        </para>
 
+      </formalpara>
+
 <programlisting>
 mysql&gt; <userinput>CREATE TABLE t (c FLOAT) PARTITION BY LIST( FLOOR(c) )(</userinput>
     -&gt;     <userinput>PARTITION p0 VALUES IN (1,3,5),</userinput>

@@ -6945,12 +6935,11 @@
 <errortext>ERROR 1490 (HY000): The PARTITION function returns the wrong type</errortext>
 </programlisting>
 
-          See <xref linkend="mathematical-functions"/>, for more
-          information about the return types of these functions.
-        </para>
+      <para>
+        See <xref linkend="mathematical-functions"/>, for more
+        information about the return types of these functions.
+      </para>
 
-      </formalpara>
-
     </section>
 
   </section>


Thread
svn commit - mysqldoc@docsrva: r23360 - in trunk: refman-5.1 refman-5.5 refman-5.6 refman-6.0jon.stephens25 Oct