List:Commits« Previous MessageNext Message »
From:jon.stephens Date:March 31 2010 9:48am
Subject:svn commit - mysqldoc@docsrva: r19791 - in trunk: refman-5.1 refman-5.4 refman-5.5 refman-6.0
View as plain text  
Author: jstephens
Date: 2010-03-31 11:48:44 +0200 (Wed, 31 Mar 2010)
New Revision: 19791

Log:

BUG#51470 -- Document as known issue



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


Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2010-03-30 20:23:22 UTC (rev 19790)
+++ trunk/refman-5.1/partitioning.xml	2010-03-31 09:48:44 UTC (rev 19791)
Changed blocks: 3, Lines Added: 115, Lines Deleted: 2; 5323 bytes

@@ -2068,6 +2068,23 @@
         partitioning</firstterm>.
       </para>
 
+      <note>
+        <para>
+          <literal>SUBPARTITION BY HASH</literal> and
+          <literal>SUBPARTITION BY KEY</literal> generally follow the
+          same syntax rules as <literal>PARTITION BY HASH</literal> and
+          <literal>PARTITION BY KEY</literal>, respectively. An
+          exception to this is that <literal>SUBPARTITION BY
+          KEY</literal> (unlike <literal>PARTITION BY KEY</literal>)
+          does not currently support a default column, so the column
+          used for this purpose must be specified, even if the table has
+          an explicit primary key. This is a known issue which we are
+          working to address; see
+          <xref linkend="partitioning-limitations-subpartitions"/>, for
+          more information and an example.
+        </para>
+      </note>
+
       <indexterm>
         <primary>dates</primary>
         <secondary>used with partitioning (examples)</secondary>

@@ -5211,15 +5228,20 @@
       </listitem>
 
       <listitem>
-        <formalpara>
+        <formalpara id="partitioning-limitations-subpartitions">
 
-          <title>Subpartitions</title>
+          <title>Issues with subpartitions</title>
 
           <indexterm>
             <primary>partitioning</primary>
             <secondary>subpartitioning</secondary>
           </indexterm>
 
+          <indexterm>
+            <primary>subpartitions</primary>
+            <secondary>known issues</secondary>
+          </indexterm>
+
           <para>
             Subpartitions are limited to <literal>HASH</literal> or
             <literal>KEY</literal> partitioning. <literal>HASH</literal>

@@ -5228,6 +5250,97 @@
           </para>
 
         </formalpara>
+
+        <indexterm>
+          <primary>SUBPARTITION BY KEY</primary>
+          <secondary>known issues</secondary>
+        </indexterm>
+
+        <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
+          table created by this statement:
+        </para>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+);
+</programlisting>
+
+        <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 (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY() 
+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>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY(id) 
+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
+          in order for the statement to succeed, as shown here:
+        </para>
+
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY()</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+<errortext>ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that 
+corresponds to your MySQL server version for the right syntax to use near ')</errortext>
+
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY(id)</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+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>
 
       <listitem>


Modified: trunk/refman-5.4/partitioning.xml
===================================================================
--- trunk/refman-5.4/partitioning.xml	2010-03-30 20:23:22 UTC (rev 19790)
+++ trunk/refman-5.4/partitioning.xml	2010-03-31 09:48:44 UTC (rev 19791)
Changed blocks: 3, Lines Added: 115, Lines Deleted: 2; 5323 bytes

@@ -1947,6 +1947,23 @@
         partitioning</firstterm>.
       </para>
 
+      <note>
+        <para>
+          <literal>SUBPARTITION BY HASH</literal> and
+          <literal>SUBPARTITION BY KEY</literal> generally follow the
+          same syntax rules as <literal>PARTITION BY HASH</literal> and
+          <literal>PARTITION BY KEY</literal>, respectively. An
+          exception to this is that <literal>SUBPARTITION BY
+          KEY</literal> (unlike <literal>PARTITION BY KEY</literal>)
+          does not currently support a default column, so the column
+          used for this purpose must be specified, even if the table has
+          an explicit primary key. This is a known issue which we are
+          working to address; see
+          <xref linkend="partitioning-limitations-subpartitions"/>, for
+          more information and an example.
+        </para>
+      </note>
+
       <indexterm>
         <primary>dates</primary>
         <secondary>used with partitioning (examples)</secondary>

@@ -5008,15 +5025,20 @@
       </listitem>
 
       <listitem>
-        <formalpara>
+        <formalpara id="partitioning-limitations-subpartitions">
 
-          <title>Subpartitions</title>
+          <title>Issues with subpartitions</title>
 
           <indexterm>
             <primary>partitioning</primary>
             <secondary>subpartitioning</secondary>
           </indexterm>
 
+          <indexterm>
+            <primary>subpartitions</primary>
+            <secondary>known issues</secondary>
+          </indexterm>
+
           <para>
             Subpartitions are limited to <literal>HASH</literal> or
             <literal>KEY</literal> partitioning. <literal>HASH</literal>

@@ -5025,6 +5047,97 @@
           </para>
 
         </formalpara>
+
+        <indexterm>
+          <primary>SUBPARTITION BY KEY</primary>
+          <secondary>known issues</secondary>
+        </indexterm>
+
+        <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
+          table created by this statement:
+        </para>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+);
+</programlisting>
+
+        <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 (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY() 
+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>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY(id) 
+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
+          in order for the statement to succeed, as shown here:
+        </para>
+
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY()</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+<errortext>ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that 
+corresponds to your MySQL server version for the right syntax to use near ')</errortext>
+
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY(id)</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+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>
 
       <listitem>


Modified: trunk/refman-5.5/partitioning.xml
===================================================================
--- trunk/refman-5.5/partitioning.xml	2010-03-30 20:23:22 UTC (rev 19790)
+++ trunk/refman-5.5/partitioning.xml	2010-03-31 09:48:44 UTC (rev 19791)
Changed blocks: 3, Lines Added: 115, Lines Deleted: 2; 5323 bytes

@@ -2959,6 +2959,23 @@
         partitioning</firstterm>.
       </para>
 
+      <note>
+        <para>
+          <literal>SUBPARTITION BY HASH</literal> and
+          <literal>SUBPARTITION BY KEY</literal> generally follow the
+          same syntax rules as <literal>PARTITION BY HASH</literal> and
+          <literal>PARTITION BY KEY</literal>, respectively. An
+          exception to this is that <literal>SUBPARTITION BY
+          KEY</literal> (unlike <literal>PARTITION BY KEY</literal>)
+          does not currently support a default column, so the column
+          used for this purpose must be specified, even if the table has
+          an explicit primary key. This is a known issue which we are
+          working to address; see
+          <xref linkend="partitioning-limitations-subpartitions"/>, for
+          more information and an example.
+        </para>
+      </note>
+
       <indexterm>
         <primary>dates</primary>
         <secondary>used with partitioning (examples)</secondary>

@@ -6130,15 +6147,20 @@
       </listitem>
 
       <listitem>
-        <formalpara>
+        <formalpara id="partitioning-limitations-subpartitions">
 
-          <title>Subpartitions</title>
+          <title>Issues with subpartitions</title>
 
           <indexterm>
             <primary>partitioning</primary>
             <secondary>subpartitioning</secondary>
           </indexterm>
 
+          <indexterm>
+            <primary>subpartitions</primary>
+            <secondary>known issues</secondary>
+          </indexterm>
+
           <para>
             Subpartitions are limited to <literal>HASH</literal> or
             <literal>KEY</literal> partitioning. <literal>HASH</literal>

@@ -6147,6 +6169,97 @@
           </para>
 
         </formalpara>
+
+        <indexterm>
+          <primary>SUBPARTITION BY KEY</primary>
+          <secondary>known issues</secondary>
+        </indexterm>
+
+        <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
+          table created by this statement:
+        </para>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+);
+</programlisting>
+
+        <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 (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY() 
+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>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY(id) 
+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
+          in order for the statement to succeed, as shown here:
+        </para>
+
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY()</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+<errortext>ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that 
+corresponds to your MySQL server version for the right syntax to use near ')</errortext>
+
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY(id)</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+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>
 
       <listitem>


Modified: trunk/refman-6.0/partitioning.xml
===================================================================
--- trunk/refman-6.0/partitioning.xml	2010-03-30 20:23:22 UTC (rev 19790)
+++ trunk/refman-6.0/partitioning.xml	2010-03-31 09:48:44 UTC (rev 19791)
Changed blocks: 3, Lines Added: 115, Lines Deleted: 2; 5323 bytes

@@ -1952,6 +1952,23 @@
         partitioning</firstterm>.
       </para>
 
+      <note>
+        <para>
+          <literal>SUBPARTITION BY HASH</literal> and
+          <literal>SUBPARTITION BY KEY</literal> generally follow the
+          same syntax rules as <literal>PARTITION BY HASH</literal> and
+          <literal>PARTITION BY KEY</literal>, respectively. An
+          exception to this is that <literal>SUBPARTITION BY
+          KEY</literal> (unlike <literal>PARTITION BY KEY</literal>)
+          does not currently support a default column, so the column
+          used for this purpose must be specified, even if the table has
+          an explicit primary key. This is a known issue which we are
+          working to address; see
+          <xref linkend="partitioning-limitations-subpartitions"/>, for
+          more information and an example.
+        </para>
+      </note>
+
       <indexterm>
         <primary>dates</primary>
         <secondary>used with partitioning (examples)</secondary>

@@ -5022,15 +5039,20 @@
       </listitem>
 
       <listitem>
-        <formalpara>
+        <formalpara id="partitioning-limitations-subpartitions">
 
-          <title>Subpartitions</title>
+          <title>Issues with subpartitions</title>
 
           <indexterm>
             <primary>partitioning</primary>
             <secondary>subpartitioning</secondary>
           </indexterm>
 
+          <indexterm>
+            <primary>subpartitions</primary>
+            <secondary>known issues</secondary>
+          </indexterm>
+
           <para>
             Subpartitions are limited to <literal>HASH</literal> or
             <literal>KEY</literal> partitioning. <literal>HASH</literal>

@@ -5039,6 +5061,97 @@
           </para>
 
         </formalpara>
+
+        <indexterm>
+          <primary>SUBPARTITION BY KEY</primary>
+          <secondary>known issues</secondary>
+        </indexterm>
+
+        <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
+          table created by this statement:
+        </para>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+);
+</programlisting>
+
+        <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 (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY() 
+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>
+
+<programlisting>
+CREATE TABLE ts (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30)
+)
+PARTITION BY KEY(id) 
+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
+          in order for the statement to succeed, as shown here:
+        </para>
+
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY()</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+<errortext>ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that 
+corresponds to your MySQL server version for the right syntax to use near ')</errortext>
+
+mysql&gt; <userinput>CREATE TABLE ts (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,</userinput>
+    -&gt;     <userinput>name VARCHAR(30)</userinput>
+    -&gt; <userinput>)</userinput>
+    -&gt; <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt; <userinput>SUBPARTITION BY KEY(id)</userinput>
+    -&gt; <userinput>SUBPARTITIONS 4</userinput>
+    -&gt; <userinput>(</userinput>
+    -&gt;     <userinput>PARTITION p0 VALUES LESS THAN (100),</userinput>
+    -&gt;     <userinput>PARTITION p1 VALUES LESS THAN (MAXVALUE)</userinput>
+    -&gt; <userinput>);</userinput>
+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>
 
       <listitem>


Thread
svn commit - mysqldoc@docsrva: r19791 - in trunk: refman-5.1 refman-5.4 refman-5.5 refman-6.0jon.stephens31 Mar