List:Commits« Previous MessageNext Message »
From:jon Date:December 13 2007 12:41pm
Subject:svn commit - mysqldoc@docsrva: r9285 - in trunk: dynamic-docs/changelog refman-5.1 refman-6.0
View as plain text  
Author: jstephens
Date: 2007-12-13 13:41:41 +0100 (Thu, 13 Dec 2007)
New Revision: 9285

Log:

Documented Partitioning bugfixes:

  Bug #29258, Bug #30480, Bug #30822, Bug #32948

Updates to Partitioning chapter:

  MAXVALUE represents a least upper bound, not a greatest possible value

  Removed references to SHOW PARTITIONS/SHOW PARTITION STATUS - this 
  was always commented out, and these statements were never implemented

  Reconciled some unneeded diffs between 5.1 and 6.0 versions



Modified:
   trunk/dynamic-docs/changelog/mysqld-1.xml
   trunk/refman-5.1/partitioning.xml
   trunk/refman-6.0/partitioning.xml


Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml	2007-12-13 08:46:56 UTC (rev 9284)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml	2007-12-13 12:41:41 UTC (rev 9285)
Changed blocks: 2, Lines Added: 150, Lines Deleted: 2; 4202 bytes

@@ -9,6 +9,154 @@
   <logentry entrytype="bug">
 
     <tags>
+      <highlight type="partitioning"/>
+      <manual type="ALTER TABLE"/>
+      <manual type="COALESCE PARTITION"/>
+      <manual type="PARTITION BY HASH"/>
+      <manual type="PARTITION BY KEY"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="30822"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.23"/>
+      <version ver="6.0.5"/>
+    </versions>
+
+    <message>
+
+      <para>
+        <literal>ALTER TABLE ... COALESCE PARTITION</literal> on a table
+        partitioned by <literal>[LINEAR] HASH</literal> or
+        <literal>[LINEAR] KEY</literal> caused the server to crash.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="partitioning"/>
+      <manual type="MAXVALUE"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="29258"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.23"/>
+      <version ver="6.0.5"/>
+    </versions>
+
+    <message>
+
+      <para>
+        It was not possible to insert the greatest possible value for a
+        given data type into a partitioned table. For example, consider
+        a table defined as shown here:
+<programlisting>
+CREATE TABLE t (c BIGINT UNSIGNED)
+    PARTITION BY RANGE(c) (
+      PARTITION p0 VALUES LESS THAN MAXVALUE
+    );
+</programlisting>
+        The largest possible value for a <literal>BIGINT
+        UNSIGNED</literal> column is 18446744073709551615, but the
+        statement <literal>INSERT INTO t VALUES
+        (18446744073709551615);</literal> would fail, even though the
+        same statement succeeded were <literal>t</literal> not a
+        partitioned table.
+      </para>
+
+      <para>
+        In other words, <literal>MAXVALUE</literal> was treated as being
+        equal to the greatest possible value, rather than as a least
+        upper bound.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="partitioning"/>
+      <manual type="Falcon"/>
+      <manual type="LIKE"/>
+      <manual type="PARTITION BY KEY"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="30480"/>
+      <seealsobug bugid="29320"/>
+      <seealsobug bugid="29493"/>
+      <seealsobug bugid="30563"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.23"/>
+      <version ver="6.0.5"/>
+    </versions>
+
+    <message ver="5.1.23">
+
+      <para>
+        <literal>LIKE</literal> queries on tables partitioned by
+        <literal>KEY</literal> and using third-party storage engines
+        could return incomplete results.
+      </para>
+
+    </message>
+
+    <message ver="6.0.5">
+
+      <para>
+        <literal>LIKE</literal> queries on tables partitioned by
+        <literal>KEY</literal> could return incomplete results. The
+        problem was observed with the <literal>Falcon</literal> storage
+        engine, but could affect third-party storage engines as well.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="partitioning"/>
+      <manual type="foreign keys"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="32948"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.1.23"/>
+      <version ver="6.0.5"/>
+    </versions>
+
+    <message>
+
+      <para>
+        It was possible to partition a table to which a foreign key
+        referred.
+      </para>
+
+    </message>
+
+  </logentry>
+
+  <logentry entrytype="bug">
+
+    <tags>
       <highlight type="cluster"/>
       <highlight type="importantchange"/>
       <manual type="AUTO_INCREMENT"/>

@@ -2084,8 +2232,8 @@
 
       <para>
         Added the <function role="sql">SHA2()</function> function, which
-        calculates the SHA-2 family of hash functions (SHA-224,
-        SHA-256, SHA-384, and SHA-512). (Contributed by Bill Karwin)
+        calculates the SHA-2 family of hash functions (SHA-224, SHA-256,
+        SHA-384, and SHA-512). (Contributed by Bill Karwin)
       </para>
 
     </message>


Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml	2007-12-13 08:46:56 UTC (rev 9284)
+++ trunk/refman-5.1/partitioning.xml	2007-12-13 12:41:41 UTC (rev 9285)
Changed blocks: 5, Lines Added: 19, Lines Deleted: 74; 5617 bytes

@@ -214,14 +214,15 @@
       <replaceable>intval</replaceable> such that
 
 <programlisting>
--MAXVALUE &lt; <replaceable>intval</replaceable> &lt; MAXVALUE
+-MAXVALUE &lt;= <replaceable>intval</replaceable> &lt;= MAXVALUE
 </programlisting>
 
-      (<literal>MAXVALUE</literal> is used to represent the greatest
-      possible positive integer.) There are some additional restrictions
-      on partitioning functions; see
-      <xref linkend="partitioning-limitations"/>, for more information
-      about these.
+      (<literal>MAXVALUE</literal> is used to represent the least upper
+      bound for the type of integer in question.
+      <literal>-MAXVALUE</literal> represents the greatest lower bound.)
+      There are some additional restrictions on partitioning functions;
+      see <xref linkend="partitioning-limitations"/>, for more
+      information about these.
     </para>
 
     <para>

@@ -856,14 +857,16 @@
       </note>
 
       <para>
-        <literal>MAXVALUE</literal> represents the greatest possible
-        integer value. Now, any rows whose <literal>store_id</literal>
-        column value is greater than or equal to 16 (the highest value
-        defined) are stored in partition <literal>p3</literal>. At some
-        point in the future &mdash; when the number of stores has
-        increased to 25, 30, or more &mdash; you can use an
-        <literal>ALTER TABLE</literal> statement to add new partitions
-        for stores 21-25, 26-30, and so on (see
+        <literal>MAXVALUE</literal> represents an integer value that is
+        always greater than the largest possible integer value (in
+        mathematical language, it serves as a <firstterm>least upper
+        bound</firstterm>). Now, any rows whose
+        <literal>store_id</literal> column value is greater than or
+        equal to 16 (the highest value defined) are stored in partition
+        <literal>p3</literal>. At some point in the future &mdash; when
+        the number of stores has increased to 25, 30, or more &mdash;
+        you can use an <literal>ALTER TABLE</literal> statement to add
+        new partitions for stores 21-25, 26-30, and so on (see
         <xref linkend="partitioning-management"/>, for details of how to
         do this).
       </para>

@@ -3757,64 +3760,6 @@
         <xref linkend="partitions-table"/>.
       </para>
 
-      <remark role="note">
-        [js] The following is commented out until it is determined
-        whether these two statements will actually be implemented.
-      </remark>
-
-<!--
-      <para>
-        Two additional <literal>SHOW</literal> commands are planned for
-        use with partitioned tables:
-      </para>
-
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            <literal>SHOW PARTITIONS</literal>
-          </para>
-
-          <para>
-            This command is expected to work similarly to <literal>SHOW
-            TABLES</literal> and <literal>SHOW DATABASES</literal>,
-            except that it will list partitions rather than tables or
-            databases. The output from this command will likely consist
-            of a single column named
-            <literal>Partitions_in_<replaceable>tbl_name</replaceable></literal>,
-            where <replaceable>tbl_name</replaceable> is the name of the
-            partitioned table. It is not possible to
-            <quote>select</quote> a table in the sense that one selects
-            a database and it thereafter serves as the default database
-            for <literal>SHOW TABLES</literal>, so it is likely that
-            <literal>SHOW PARTITIONS</literal> will require the use of a
-            <literal>FROM</literal> clause so that MySQL knows which
-            table is intended.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <literal>SHOW PARTITION STATUS</literal>
-          </para>
-
-          <para>
-            This command will provide detailed status information about
-            one or more partitions. Its output will likely contain the
-            same columns as or columns similar to those found in the
-            output of <literal>SHOW TABLE STATUS</literal>, with the
-            addition of columns showing the data and index directories
-            used for the partition. This command is likely to support
-            <literal>LIKE</literal> and <literal>FROM</literal> clauses
-            that will make it possible to obtain information about a
-            given partition by name, or about partitions belonging to
-            specific table or database.
-          </para>
-        </listitem>
-
-      </itemizedlist>
--->
-
       <indexterm>
         <primary>partitioning</primary>
         <secondary>optimization</secondary>

@@ -3982,7 +3927,7 @@
 
     <para>
       This section discusses <firstterm>partition pruning</firstterm>,
-      an opimisation which was implemented for partitioned tables in
+      an optimization which was implemented for partitioned tables in
       MySQL 5.1.6. The core concept behind partition pruning is
       relatively simple, and can be described as <quote>Do not scan
       partitions where there can be no matching values</quote>. For

@@ -4484,7 +4429,7 @@
       <listitem>
         <formalpara>
 
-          <title>Foreign keys</title>
+          <title>Foreign keys not supported</title>
 
           <indexterm>
             <primary>partitioning</primary>


Modified: trunk/refman-6.0/partitioning.xml
===================================================================
--- trunk/refman-6.0/partitioning.xml	2007-12-13 08:46:56 UTC (rev 9284)
+++ trunk/refman-6.0/partitioning.xml	2007-12-13 12:41:41 UTC (rev 9285)
Changed blocks: 7, Lines Added: 36, Lines Deleted: 75; 6656 bytes

@@ -198,11 +198,12 @@
 -MAXVALUE &lt; <replaceable>intval</replaceable> &lt; MAXVALUE
 </programlisting>
 
-      (<literal>MAXVALUE</literal> is used to represent the greatest
-      possible positive integer.) There are some additional restrictions
-      on partitioning functions; see
-      <xref linkend="partitioning-limitations"/>, for more information
-      about these.
+      (<literal>MAXVALUE</literal> is used to represent the least upper
+      bound for the type of integer in question.
+      <literal>-MAXVALUE</literal> represents the greatest lower bound.)
+      There are some additional restrictions on partitioning functions;
+      see <xref linkend="partitioning-limitations"/>, for more
+      information about these.
     </para>
 
     <para>

@@ -823,14 +824,16 @@
       </note>
 
       <para>
-        <literal>MAXVALUE</literal> represents the greatest possible
-        integer value. Now, any rows whose <literal>store_id</literal>
-        column value is greater than or equal to 16 (the highest value
-        defined) are stored in partition <literal>p3</literal>. At some
-        point in the future &mdash; when the number of stores has
-        increased to 25, 30, or more &mdash; you can use an
-        <literal>ALTER TABLE</literal> statement to add new partitions
-        for stores 21-25, 26-30, and so on (see
+        <literal>MAXVALUE</literal> represents an integer value that is
+        always greater than the largest possible integer value (in
+        mathematical language, it serves as a <firstterm>least upper
+        bound</firstterm>). Now, any rows whose
+        <literal>store_id</literal> column value is greater than or
+        equal to 16 (the highest value defined) are stored in partition
+        <literal>p3</literal>. At some point in the future &mdash; when
+        the number of stores has increased to 25, 30, or more &mdash;
+        you can use an <literal>ALTER TABLE</literal> statement to add
+        new partitions for stores 21-25, 26-30, and so on (see
         <xref linkend="partitioning-management"/>, for details of how to
         do this).
       </para>

@@ -3658,64 +3661,6 @@
         <xref linkend="partitions-table"/>.
       </para>
 
-      <remark role="note">
-        [js] The following is commented out until it is determined
-        whether these two statements will actually be implemented.
-      </remark>
-
-<!--
-      <para>
-        Two additional <literal>SHOW</literal> commands are planned for
-        use with partitioned tables:
-      </para>
-
-      <itemizedlist>
-
-        <listitem>
-          <para>
-            <literal>SHOW PARTITIONS</literal>
-          </para>
-
-          <para>
-            This command is expected to work similarly to <literal>SHOW
-            TABLES</literal> and <literal>SHOW DATABASES</literal>,
-            except that it will list partitions rather than tables or
-            databases. The output from this command will likely consist
-            of a single column named
-            <literal>Partitions_in_<replaceable>tbl_name</replaceable></literal>,
-            where <replaceable>tbl_name</replaceable> is the name of the
-            partitioned table. It is not possible to
-            <quote>select</quote> a table in the sense that one selects
-            a database and it thereafter serves as the default database
-            for <literal>SHOW TABLES</literal>, so it is likely that
-            <literal>SHOW PARTITIONS</literal> will require the use of a
-            <literal>FROM</literal> clause so that MySQL knows which
-            table is intended.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            <literal>SHOW PARTITION STATUS</literal>
-          </para>
-
-          <para>
-            This command will provide detailed status information about
-            one or more partitions. Its output will likely contain the
-            same columns as or columns similar to those found in the
-            output of <literal>SHOW TABLE STATUS</literal>, with the
-            addition of columns showing the data and index directories
-            used for the partition. This command is likely to support
-            <literal>LIKE</literal> and <literal>FROM</literal> clauses
-            that will make it possible to obtain information about a
-            given partition by name, or about partitions belonging to
-            specific table or database.
-          </para>
-        </listitem>
-
-      </itemizedlist>
--->
-
       <indexterm>
         <primary>partitioning</primary>
         <secondary>optimization</secondary>

@@ -3882,7 +3827,7 @@
     </indexterm>
 
     <para>
-      This section discusses an optimisation known as
+      This section discusses an optimization known as
       <firstterm>partition pruning</firstterm>. The core concept behind
       partition pruning is relatively simple, and can be described as
       <quote>Do not scan partitions where there can be no matching

@@ -4372,7 +4317,7 @@
 
         <para>
           If, when creating tables with a very large number of
-          partitions (but which is less than the maxmimum stated
+          partitions (but which is less than the maximum stated
           previously), you encounter an error message such as
           <errortext>Got error 24 from storage engine</errortext>, this
           means that you may need to increase the value of the

@@ -4414,8 +4359,8 @@
 
             </orderedlist>
 
-            The scope of these restrictions includes partitioned tables
-            employing the <literal>InnoDB</literal> storage engine.
+            The scope of these restrictions includes tables that use the
+            <literal>InnoDB</literal> storage engine.
           </para>
 
         </formalpara>

@@ -4618,6 +4563,22 @@
       <listitem>
         <formalpara>
 
+          <title>Performance with <literal>LOAD DATA</literal></title>
+
+          <para>
+            Prior to MySQL 6.0.4, <literal>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>
+
+        </formalpara>
+      </listitem>
+
+      <listitem>
+        <formalpara>
+
           <title><literal>DATA DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
             options</title>
 


Thread
svn commit - mysqldoc@docsrva: r9285 - in trunk: dynamic-docs/changelog refman-5.1 refman-6.0jon13 Dec