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
List-Archive: http://lists.mysql.com/commits/39886
Message-Id: <200712131241.lBDCfgeU009053@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ALTER TABLE ... COALESCE PARTITION on a table
+ partitioned by [LINEAR] HASH or
+ [LINEAR] KEY caused the server to crash.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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:
+
+CREATE TABLE t (c BIGINT UNSIGNED)
+ PARTITION BY RANGE(c) (
+ PARTITION p0 VALUES LESS THAN MAXVALUE
+ );
+
+ The largest possible value for a BIGINT
+ UNSIGNED column is 18446744073709551615, but the
+ statement INSERT INTO t VALUES
+ (18446744073709551615); would fail, even though the
+ same statement succeeded were t not a
+ partitioned table.
+
+
+
+ In other words, MAXVALUE was treated as being
+ equal to the greatest possible value, rather than as a least
+ upper bound.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ LIKE queries on tables partitioned by
+ KEY and using third-party storage engines
+ could return incomplete results.
+
+
+
+
+
+
+
+ LIKE queries on tables partitioned by
+ KEY could return incomplete results. The
+ problem was observed with the Falcon storage
+ engine, but could affect third-party storage engines as well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ It was possible to partition a table to which a foreign key
+ referred.
+
+
+
+
+
+
+
+
+
@@ -2084,8 +2232,8 @@
Added the SHA2() 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)
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 @@
intval such that
--MAXVALUE < intval < MAXVALUE
+-MAXVALUE <= intval <= MAXVALUE
- (MAXVALUE is used to represent the greatest
- possible positive integer.) There are some additional restrictions
- on partitioning functions; see
- , for more information
- about these.
+ (MAXVALUE is used to represent the least upper
+ bound for the type of integer in question.
+ -MAXVALUE represents the greatest lower bound.)
+ There are some additional restrictions on partitioning functions;
+ see , for more
+ information about these.
@@ -856,14 +857,16 @@
- MAXVALUE represents the greatest possible
- integer value. Now, any rows whose store_id
- column value is greater than or equal to 16 (the highest value
- defined) are stored in partition p3. At some
- point in the future — when the number of stores has
- increased to 25, 30, or more — you can use an
- ALTER TABLE statement to add new partitions
- for stores 21-25, 26-30, and so on (see
+ MAXVALUE represents an integer value that is
+ always greater than the largest possible integer value (in
+ mathematical language, it serves as a least upper
+ bound). Now, any rows whose
+ store_id column value is greater than or
+ equal to 16 (the highest value defined) are stored in partition
+ p3. At some point in the future — when
+ the number of stores has increased to 25, 30, or more —
+ you can use an ALTER TABLE statement to add
+ new partitions for stores 21-25, 26-30, and so on (see
, for details of how to
do this).
@@ -3757,64 +3760,6 @@
.
-
- [js] The following is commented out until it is determined
- whether these two statements will actually be implemented.
-
-
-
-
partitioning
optimization
@@ -3982,7 +3927,7 @@
This section discusses partition pruning,
- 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 Do not scan
partitions where there can be no matching values
. For
@@ -4484,7 +4429,7 @@
- Foreign keys
+ Foreign keys not supported
partitioning
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 < intval < MAXVALUE
- (MAXVALUE is used to represent the greatest
- possible positive integer.) There are some additional restrictions
- on partitioning functions; see
- , for more information
- about these.
+ (MAXVALUE is used to represent the least upper
+ bound for the type of integer in question.
+ -MAXVALUE represents the greatest lower bound.)
+ There are some additional restrictions on partitioning functions;
+ see , for more
+ information about these.
@@ -823,14 +824,16 @@
- MAXVALUE represents the greatest possible
- integer value. Now, any rows whose store_id
- column value is greater than or equal to 16 (the highest value
- defined) are stored in partition p3. At some
- point in the future — when the number of stores has
- increased to 25, 30, or more — you can use an
- ALTER TABLE statement to add new partitions
- for stores 21-25, 26-30, and so on (see
+ MAXVALUE represents an integer value that is
+ always greater than the largest possible integer value (in
+ mathematical language, it serves as a least upper
+ bound). Now, any rows whose
+ store_id column value is greater than or
+ equal to 16 (the highest value defined) are stored in partition
+ p3. At some point in the future — when
+ the number of stores has increased to 25, 30, or more —
+ you can use an ALTER TABLE statement to add
+ new partitions for stores 21-25, 26-30, and so on (see
, for details of how to
do this).
@@ -3658,64 +3661,6 @@
.
-
- [js] The following is commented out until it is determined
- whether these two statements will actually be implemented.
-
-
-
-
partitioning
optimization
@@ -3882,7 +3827,7 @@
- This section discusses an optimisation known as
+ This section discusses an optimization known as
partition pruning. The core concept behind
partition pruning is relatively simple, and can be described as
Do not scan partitions where there can be no matching
@@ -4372,7 +4317,7 @@
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
Got error 24 from storage engine, this
means that you may need to increase the value of the
@@ -4414,8 +4359,8 @@
- The scope of these restrictions includes partitioned tables
- employing the InnoDB storage engine.
+ The scope of these restrictions includes tables that use the
+ InnoDB storage engine.
@@ -4618,6 +4563,22 @@
+ Performance with <literal>LOAD DATA</literal>
+
+
+ Prior to MySQL 6.0.4, LOAD DATA 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)
+
+
+
+
+
+
+
+
<literal>DATA DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal>
options