Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.3631 05/09/28 02:35:03 jon@stripped +3 -0
Partitioning:
- Syntax and related fixes (VALUES and PARTITIONS
clauses were wrong).
- Moved discussion of hashing and linear hashing
algorithms from SQL Syntax to Partitioning chapter.
- Added new Linear Hashing section to Partitioning
chapter.
- Added some notes/warnings/etc. to Partitioning and
SQL Syntax chapters.
refman-common/titles.en.ent
1.50 05/09/28 02:35:01 jon@stripped +1 -0
Added title of new Linear Hashing
section for Partitioning chapter.
refman-5.1/sql-syntax.xml
1.54 05/09/28 02:35:01 jon@stripped +99 -199
CREATE TABLE/partitioning:
- Syntax and misc. fixes.
- Added some notes and warnings.
- Cut description of [LINEAR] HASH algorithms
(moved to Partitioning chapter).
- Corrected usage of VALUES LESS THAN and VALUES
IN clauses.
refman-5.1/partitioning.xml
1.15 05/09/28 02:35:01 jon@stripped +234 -28
- Syntax fixes.
- Moved discussion of [LINEAR] HASH algorithms
here from sql-syntax.
- Created new section for linear hashing.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.
# Root: /home/jon/bk/mysqldoc2
--- 1.14/refman-5.1/partitioning.xml 2005-09-27 10:45:14 +10:00
+++ 1.15/refman-5.1/partitioning.xml 2005-09-28 02:35:01 +10:00
@@ -688,15 +688,16 @@
<literal>pC</literal>. It is important to note that there is no
<quote>catch-all</quote> definition for list partitions
analogous to <literal>VALUES LESS THAN (MAX_VALUE)</literal>
- which can accommodate values not found in any of the value lists.
- Any value which is to be matched must be found in one of the
+ for accommodating values not found in any of the value lists.
+ Any value which is to be matched must be found in one of the
value lists.
</para>
<para>
- It is possible to combine <literal>LIST</literal> partitioning
- with partitioning by hash or key. For a discussion of this, see
- <xref linkend="partitioning-subpartitions"/>.
+ As with <literal>RANGE</literal> partitioning, it is possible to
+ combine <literal>LIST</literal> partitioning with partitioning
+ by hash or key. For a discussion of this, see <xref
+ linkend="partitioning-subpartitions"/>.
</para>
</section>
@@ -748,7 +749,7 @@
store_id INT
)
PARTITION BY HASH(store_id)
-PARTITIONS(4);
+PARTITIONS 4;
</programlisting>
<para>
@@ -780,11 +781,11 @@
store_id INT
)
PARTITION BY HASH(YEAR(hired))
-PARTITIONS(4);
+PARTITIONS 4;
</programlisting>
<para>
- You may use any functional or other expression for
+ You may use any function or other expression for
<replaceable>expr</replaceable> that is valid in MySQL, so long
as it returns a non-constant, non-random integer value. (In
other words, it should be varying but deterministic.) However,
@@ -792,7 +793,7 @@
time a row is inserted, updated, or deleted; this means that
very complex expressions may give rise to performance issues,
particularly when performing operations (such as batch inserts)
- that affect a great many rows.
+ that affect a great many rows at a time.
</para>
<para>
@@ -805,21 +806,81 @@
expressions involving multiple columns is not particularly
recommended.
</para>
+
+ <para>
+ When <literal>PARTITION BY HASH</literal> is used, MySQL
+ determines which partition of
+ <replaceable>num</replaceable> partitions to use based
+ on the modulus of the result of the user function. In
+ other words, for an expression
+ <replaceable>expr</replaceable>, the partition in which
+ the record is stored is partition number
+ <replaceable>N</replaceable>, where
+ <literal><replaceable>N</replaceable> =
+ MOD(<replaceable>expr</replaceable>,
+ <replaceable>num</replaceable>)</literal>. For
+ example, suppose table <literal>t1</literal> is defined
+ as follows, so that it has 4 partitions:
+ </para>
+
+<programlisting>
+CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
+ PARTITION BY HASH( YEAR(col3) )
+ PARTITIONS 4;
+</programlisting>
+
+ <para>
+ If you insert a record into <literal>t1</literal> whose
+ <literal>col3</literal> value is
+ <literal>'2005-09-15'</literal>, then the partition in
+ which it is stored is determined as follows:
+ </para>
+
+<programlisting>
+MOD(YEAR('2005-09-01'),5)
+= MOD(2004,4)
+= 1
+</programlisting>
<para>
- MySQL also supports linear hashing, which differs from regular
- hashing in that linear hashing utilizes a linear powers-of-two
- algorithm whereas regular hashing employs the modulus of the
- hashing function's value. (See <xref linkend="create-table"/>
- for details.)
+ MySQL ¤t-series; also supports a variant known as
+ <firstterm>linear hashing</firstterm> which employs a more
+ complex algortihm for determining the placement of new rows
+ inserted into the partitioned table. See <xref
+ linkend="partitioning-linear-hash"/>.
</para>
<para>
- Syntactically, the only difference between linear-hash
- partitioning and regular hashing is the addition of the
- <literal>LINEAR</literal> keyword in the <literal>PARTITION
- BY</literal> clause, as shown here:
+ The user function is evaluated each time a record is
+ inserted, updated, or deleted.
</para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: If the table to
+ be partitioned has a <literal>UNIQUE</literal> key, then
+ any columns supplied as arguments to the
+ <literal>HASH</literal> user function or to the
+ <literal>KEY</literal>'s
+ <replaceable>column_list</replaceable> must be part of
+ that key.
+ </para>
+
+ <section id="partitioning-linear-hash">
+ <title id="title-partitioning-linear-hash">&title-partitioning-linear-hash;</title>
+
+ <para>
+ MySQL also supports linear hashing, which differs from regular
+ hashing in that linear hashing utilizes a linear powers-of-two
+ algorithm whereas regular hashing employs the modulus of the
+ hashing function's value.
+ </para>
+
+ <para>
+ Syntactically, the only difference between linear-hash
+ partitioning and regular hashing is the addition of the
+ <literal>LINEAR</literal> keyword in the <literal>PARTITION
+ BY</literal> clause, as shown here:
+ </para>
<programlisting>
CREATE TABLE employees (
@@ -832,17 +893,123 @@
store_id INT
)
PARTITION BY LINEAR HASH(YEAR(hired))
-PARTITIONS(4);
+PARTITIONS 4;
+</programlisting>
+
+ <para>Given an expression <replaceable>expr</replaceable>, the
+ partition in which the record is stored when linear hashing used
+ is partition number <replaceable>N</replaceable> from among
+ <replaceable>num</replaceable> partitions, where
+ <replaceable>N</replaceable> is derived according to the
+ following algorithm:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Find the next power of 2 greater than
+ <replaceable>num</replaceable>. We call this value
+ <replaceable>V</replaceable>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Set <replaceable>N</replaceable> =
+ <replaceable>F</replaceable>(<replaceable>column_list</replaceable>)
+ & (<replaceable>V</replaceable> - 1).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ While <replaceable>N</replaceable> >=
+ <replaceable>num</replaceable>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Set <replaceable>V</replaceable> =
+ <replaceable>V</replaceable> / 2
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Set <replaceable>N</replaceable> =
+ <replaceable>N</replaceable> &
+ (<replaceable>V</replaceable> - 1)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ For example, suppose that the table
+ <literal>t1</literal>, using linear hash partitioning
+ and having 4 partitions, is created using this
+ statement:
+ </para>
+
+<programlisting>
+CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
+ PARTITION BY LINEAR HASH( YEAR(col3) )
+ 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>'1999-10-19'</literal>. The partition number
+ for the first of these is determined as follows:
+ </para>
+
+<programlisting>
+<replaceable>V</replaceable> = 8
+<replaceable>N</replaceable> = YEAR('2003-04-14') & (8 - 1)
+ = 2003 & 7
+ = 3
+
+(<emphasis>3 >= 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
+<replaceable>N</replaceable> = YEAR('1999-10-19') & (4 + 1)
+ = 2004 & 5
+ = 4
+
+(<emphasis>4 >= 4 is TRUE: additional step required</emphasis>)
+
+<replaceable>N</replaceable> = 4 & CEILING(4 / 2)
+ = 4 & 2
+ = 0
+
+(<emphasis>0 >= 4 is FALSE: record stored in partition #0</emphasis>)
</programlisting>
- <para>
- The advantage in partitioning by linear hash is that the
- addition of a new partition by splitting an existing one is made
- much faster, which can be beneficial whn dealing with tables
- containing extremely large amounts (terabytes) of data. The
- disadvantage is that data is not evenly distributed between
- partitions.
- </para>
+ <para>
+ The advantage in partitioning by linear hash is that the
+ adding, dropping, merging, and splitting of partitions is made
+ much faster, which can be beneficial when dealing with tables
+ containing extremely large amounts (terabytes) of data. The
+ disadvantage is that data is not evenly distributed between
+ partitions.
+ </para>
+
+ </section>
</section>
@@ -850,7 +1017,46 @@
<title id="title-partitioning-key">&title-partitioning-key;</title>
<para>
- This section discusses partitioning by key.
+ Partitioning by key is similar to partitioning by hash, except
+ that where hash partitioning employs a user-defined expression,
+ the hashing function for key partitioning is supplied by the
+ MySQL server. MySQL Cluster uses <literal>MD5()</literal> for
+ this purpose; for tables using other storage engines, the server
+ employs its own internal hashing function which is based on the
+ same algorithm as <literal>PASSWORD()</literal>.
+ </para>
+
+ <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 only differences are that you use
+ <literal>KEY</literal> rather than <literal>HASH</literal>, and
+ that <literal>KEY</literal> takes only a list of one or more
+ column names.
+ </para>
+
+ <para>
+ It is also possible to partition a table by linear key. Here is
+ a simple example:
+ </para>
+
+<programlisting>
+CREATE TABLE tk (
+ col1 INT NOT NULL,
+ col2 CHAR(5),
+ col3 DATE
+)
+PARTITION BY LINEAR KEY (col1)
+PARTITIONS 3;
+</programlisting>
+
+ <para>
+ Using <literal>LINEAR</literal> has the same effect on
+ <literal>KEY</literal> partitioning as it does on
+ <literal>HASH</literal> partitioning, with the partition number
+ being derived using a powers-of-two algorithm rather than modulo
+ arithmetic. See <xref linkend="partitioning-linear-hash"/> for a
+ description of this algorithm and its implications.
</para>
</section>
--- 1.53/refman-5.1/sql-syntax.xml 2005-09-22 08:57:30 +10:00
+++ 1.54/refman-5.1/sql-syntax.xml 2005-09-28 02:35:01 +10:00
@@ -1487,7 +1487,7 @@
| [LINEAR] KEY(<replaceable>column_list</replaceable>)
| RANGE(<replaceable>expr</replaceable>)
| LIST(<replaceable>column_list</replaceable>)
- [PARTITIONS(<replaceable>num</replaceable>) ]
+ [PARTITIONS <replaceable>num</replaceable>]
[ SUBPARTITION BY
[LINEAR] HASH(<replaceable>expr</replaceable>)
| [LINEAR] KEY(<replaceable>column_list</replaceable>)
@@ -1922,7 +1922,7 @@
<para>
In this case, <literal>i</literal> has no explicit default,
so in strict mode all of the following statements produce an
- error in strict mode and no row is inserted. For non strict
+ error and no row is inserted. For non strict
mode, only the third statement produces an error; the
implicit default is inserted for the first two, but the
third fails because <literal>DEFAULT(i)</literal> cannot
@@ -2729,22 +2729,28 @@
from 1 to <replaceable>num</replaceable>, where
<replaceable>num</replaceable> is the number of partitions.
The choices available for this function which are available
- in MySQL ¤t-series; are:
+ in MySQL ¤t-series; are shown in the following list.
+ <emphasis role="bold">Important</emphasis>: Not all options
+ shown in the syntax for
+ <replaceable>partition_options</replaceable> at the
+ beginning of this section are available for all partitioning
+ types. Please see the listings for the individual types
+ below for more complete information.
</para>
<itemizedlist>
<listitem>
<para>
- <literal>HASH(<replaceable>func_expr</replaceable>)</literal>:
+ <literal>HASH(<replaceable>expr</replaceable>)</literal>:
Hashes one or more columns to create a key for placing
- and locating rows. <replaceable>func_expr</replaceable>
- is an expression consisting of a user-supplied function,
- taking as arguments one or more table columns. This can
- be any legal MySQL expression that yields a single
- integer value. For example, these are all valid
- <literal>CREATE TABLE</literal> statements using
- <literal>PARTITION BY HASH</literal>:
+ and locating rows. <replaceable>expr</replaceable>
+ is an expression using one or more table columns. This
+ can be any legal MySQL expression (including MySQL
+ functions) that yields a single integer value. For
+ example, these are all valid <literal>CREATE
+ TABLE</literal> statements using <literal>PARTITION BY
+ HASH</literal>:
</para>
<programlisting>
@@ -2757,173 +2763,28 @@
CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATETIME)
PARTITION BY HASH ( YEAR(col3) );
</programlisting>
-
- <para>
- When <literal>PARTITION BY HASH</literal> is used, MySQL
- determines which partition of
- <replaceable>num</replaceable> partitions to use based
- on the modulus of the result of the user function. In
- other words, for a user function
- <replaceable>F</replaceable>, the partition in which the
- record is stored is partition number
- <replaceable>N</replaceable>, where
- <literal><replaceable>N</replaceable> =
- mod(<replaceable>F</replaceable>(<replaceable>column_list</replaceable>),
- <replaceable>num</replaceable>)</literal>. For example,
- suppose table <literal>t1</literal> is defined as
- follows, so that it has 4 partitions:
- </para>
-
-<programlisting>
-CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
- PARTITION BY HASH( YEAR(col3) )
- PARTITIONS(4);
-</programlisting>
-
+
<para>
- If you insert a record into <literal>t1</literal> whose
- <literal>col3</literal> value is
- <literal>'2005-09-15'</literal>, then the partition in
- which it is stored is determined as follows:
+ You may not use either <literal>VALUES LESS
+ THAN</literal> or <literal>VALUES IN</literal> clauses
+ with <literal>PARTITION BY HASH</literal>.
</para>
-
-<programlisting>
-MOD(YEAR('2005-09-01'),5)
-= MOD(2004,4)
-= 1
-</programlisting>
-
+
<para>
- The user function is evaluated each time a record is
- inserted, updated, or deleted.
+ <literal>PARTITION BY HASH</literal> uses the remainder
+ of <replaceable>expr</replaceable> divided by the number
+ of partitions (that is, the modulus). For examples and
+ additional information, see <xref
+ linkend="partitioning-hash"/>.
</para>
-
+
<para>
The <literal>LINEAR</literal> keyword entails a somewhat
different algorithm. In this case, the number of the
partition in which a record is stored is calculated as
the result of one or more logical <literal>AND</literal>
- operations. In other words, for a user function
- <replaceable>F</replaceable>, the partition in which the
- record is stored is partition number
- <replaceable>N</replaceable> from among
- <replaceable>num</replaceable> partitions, where
- <replaceable>N</replaceable> is derived according to the
- following algorithm:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Find the next power of 2 greater than
- <replaceable>num</replaceable>. We call this value
- <replaceable>V</replaceable>.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Set <replaceable>N</replaceable> =
- <replaceable>F</replaceable>(<replaceable>column_list</replaceable>)
- & (<replaceable>V</replaceable> - 1).
- </para>
- </listitem>
-
- <listitem>
- <para>
- While <replaceable>N</replaceable> >=
- <replaceable>num</replaceable>:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- Set <replaceable>V</replaceable> =
- <replaceable>V</replaceable> / 2
- </para>
- </listitem>
-
- <listitem>
- <para>
- Set <replaceable>N</replaceable> =
- <replaceable>N</replaceable> &
- (<replaceable>V</replaceable> - 1)
- </para>
- </listitem>
-
- </itemizedlist>
- </listitem>
-
- </orderedlist>
-
- <para>
- For example, suppose that the table
- <literal>t1</literal>, using linear hash partitioning
- and having 4 partitions, is created using this
- statement:
- </para>
-
-<programlisting>
-CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
- PARTITION BY LINEAR HASH( YEAR(col3) )
- 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>'1999-10-19'</literal>. The partition number
- for the first of these is determined as follows:
- </para>
-
-<programlisting>
-<replaceable>V</replaceable> = 8
-<replaceable>N</replaceable> = YEAR('2003-04-14') & (8 - 1)
- = 2003 & 7
- = 3
-
-(<emphasis>3 >= 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
-<replaceable>N</replaceable> = YEAR('1999-10-19') & (4 + 1)
- = 2004 & 5
- = 4
-
-(<emphasis>4 >= 4 is TRUE: additional step required</emphasis>)
-
-<replaceable>N</replaceable> = 4 & CEILING(4 / 2)
- = 4 & 2
- = 0
-
-(<emphasis>0 >= 4 is FALSE: record stored in partition #0</emphasis>)
-</programlisting>
-
- <para>
- Linear hashing makes it less expensive to add, drop,
- split, or merge partitions; however, the data
- distribution is uneven compared to that produced by
- normal hash or key partitioning. For more information,
- see <xref linkend="partitioning"/>.
- </para>
-
- <para>
- <emphasis role="bold">Note</emphasis>: If the table to
- be partitioned has a <literal>UNIQUE</literal> key, then
- any columns supplied as arguments to the
- <literal>HASH</literal> user function or to the
- <literal>KEY</literal>'s
- <replaceable>column_list</replaceable> must be part of
- that key.
+ operations. For discussion and examples of linear
+ hashing, see <xref linkend="partitioning-linear-hash"/>.
</para>
</listitem>
@@ -2932,10 +2793,7 @@
<literal>KEY(<replaceable>column_list</replaceable>)</literal>:
This is similar to <literal>HASH</literal>, except that
MySQL supplies the hashing function so as to guarantee
- an even data distribution. (MySQL Cluster uses
- <literal>MD5()</literal> for this purpose; for tables
- using other storage engines, the server employs its own
- internal hashing function.) The
+ an even data distribution. The
<replaceable>column_list</replaceable> argument is
simply a list of table columns. This example shows a
simple table partitioned by key, with 4 partitions:
@@ -2944,7 +2802,7 @@
<programlisting>
CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE)
PARTITION BY KEY(col3)
- PARTITIONS(4);
+ PARTITIONS 4;
</programlisting>
<para>
@@ -2954,24 +2812,35 @@
effect as with tables that are partitioned by
<literal>HASH</literal>; that is, the partition number
is found using the <literal>&</literal> operator
- rather than the modulus as previously described in this
- section. This example uses linear partitioning by key to
- distribute data between 5 partitions:
+ rather than the modulus (see <xref
+ linkend="partitioning-linear-hash"/> and <xref
+ linkend="partitioning-key"/> for details). This
+ example uses linear partitioning by key to distribute
+ data between 5 partitions:
</para>
<programlisting>
CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE)
PARTITION BY LINEAR KEY(col3)
- PARTITIONS(5);
+ PARTITIONS 5;
</programlisting>
+
+ <para>
+ You may not use either <literal>VALUES LESS
+ THAN</literal> or <literal>VALUES IN</literal> clauses
+ with <literal>PARTITION BY KEY</literal>.
+ </para>
</listitem>
<listitem>
<para>
<literal>RANGE</literal>: In this case,
<replaceable>expr</replaceable> shows a range of values
- using a set of <literal>VALUES LESS THAN</literal> or
- <literal>VALUES IN</literal> operators.
+ using a set of <literal>VALUES LESS THAN</literal>
+ operators. When using range partitioning, you must
+ define at least one partition using <literal>VALUES LESS
+ THAN</literal>. You cannot use<literal>VALUES
+ IN</literal> with range partitioning.
</para>
<para>
@@ -3122,6 +2991,13 @@
<literal>VALUES IN</literal> may be used to specify
allowable values for each partition.
</para>
+
+ <para>
+ When using list partitioning, you must define at least
+ one partition using <literal>VALUES IN</literal>. You
+ cannot use <literal>VALUES LESS THAN</literal> with
+ <literal>PARTITION BY LIST</literal>.
+ </para>
</listitem>
<listitem>
@@ -3173,12 +3049,14 @@
<listitem>
<para>
- An optional <literal>VALUES</literal> clause: This may
- be either a <literal>VALUES LESS THAN</literal> or a
- <literal>VALUES IN</literal> clause as discussed above,
- and is used to determine which rows are to be stored in
- this partition. See the discussion of partitioning types
- for syntax examples.
+ A <literal>VALUES</literal> clause: For range
+ partitioning, each partition must include a
+ <literal>VALUES LESS THAN</literal> clause; for list
+ partitioning, you must specify a <literal>VALUES IN</literal>
+ clause for each partition. This is used to determine
+ which rows are to be stored in this partition. See the
+ discussions of partitioning types in <xref
+ linkend="partitioning"/> for syntax examples.
</para>
</listitem>
@@ -3207,9 +3085,14 @@
</para>
<programlisting>
-DATA DIRECTORY = '<filename>/var/appdata/1999/data</filename>'
-INDEX DIRECTORY = '<filename>/var/appdata/1999/indexes</filename>'
-</programlisting>
+CREATE TABLE th (id INT, name VARCHAR(30), adate DATE)
+PARTITION BY LIST(YEAR(adate))
+(
+ PARTITION p1999 VALUES IN (1995, 1999, 2003) DATA DIRECTORY = '<filename>/var/appdata/95/data</filename>' INDEX DIRECTORY = '<filename>/var/appdata/95/idx</filename>',
+ PARTITION p2000 VALUES IN (1996, 2000, 2004) DATA DIRECTORY = '<filename>/var/appdata/96/data</filename>' INDEX DIRECTORY = '<filename>/var/appdata/96/idx</filename>',
+ PARTITION p2001 VALUES IN (1997, 2001, 2005) DATA DIRECTORY = '<filename>/var/appdata/97/data</filename>' INDEX DIRECTORY = '<filename>/var/appdata/97/idx</filename>',
+ PARTITION p2000 VALUES IN (1998, 2002, 2006) DATA DIRECTORY = '<filename>/var/appdata/98/data</filename>' INDEX DIRECTORY = '<filename>/var/appdata/98/idx</filename>'
+);</programlisting>
<para>
<literal>DATA DIRECTORY</literal> and <literal>INDEX
@@ -3222,7 +3105,9 @@
<para>
One data directory and one index directory may be
- specified per partition.
+ specified per partition. If left unspecified, then the
+ data and indexes are stored in the default MySQL data
+ directory.
</para>
</listitem>
@@ -3234,7 +3119,10 @@
be stored in the partition. The values for
<replaceable>max_number_of_rows</replaceable> and
<replaceable>min_number_of_rows</replaceable> must be
- positive integers.
+ positive integers. As with the table-level options with
+ the same names, these act only as
+ <quote>suggestions</quote> to the server and are not
+ hard limits.
</para>
</listitem>
@@ -3244,8 +3132,12 @@
used to designate a tablespace for the partition. Used
for MySQL Cluster only.
</para>
+
+ <remark role="note">
+ [js] Next item commented out until actually implemented.
+ </remark>
</listitem>
-
+<!--
<listitem>
<para>
The optional <literal>[STORAGE] ENGINE</literal> clause
@@ -3258,7 +3150,7 @@
as a whole is used for this partition.
</para>
</listitem>
-
+-->
<listitem>
<para>
The <literal>NODEGROUP</literal> option can be used to
@@ -3282,20 +3174,28 @@
subpartition definition is identical to that for a
partition definition.
</para>
+
+ <para>
+ Subpartitioning must be done by <literal>HASH</literal>
+ or <literal>KEY</literal>, and can be done only on
+ <literal>RANGE</literal> or <literal>LIST</literal>
+ partitions. See <xref
+ linkend="partitioning-subpartitions"/>.
+ </para>
</listitem>
</itemizedlist>
<para>
- Partitions can be modified, added to tables, and dropped
- from tables. For more information about this, see
- <xref linkend="alter-table"/>.
+ Partitions can be modified, merged, added to tables, and
+ dropped from tables. For basic information about the MySQL
+ commands to accomplish these tasks, see <xref
+ linkend="alter-table"/>.
</para>
<para>
- For a more information including a theoretical description
- of partitioning in MySQL, see
- <xref linkend="partitioning"/>.
+ For more complete information on partitioning in MySQL, see
+ <xref linkend="partitioning"/>.
</para>
</listitem>
--- 1.49/refman-common/titles.en.ent 2005-09-26 21:40:37 +10:00
+++ 1.50/refman-common/titles.en.ent 2005-09-28 02:35:01 +10:00
@@ -1230,6 +1230,7 @@
<!ENTITY title-partitioning-types "MySQL Partition Types">
<!ENTITY title-partitioning-key "Partitioning by Key">
<!ENTITY title-partitioning-hash "Partitioning by Hash">
+<!ENTITY title-partitioning-linear-hash "Partitioning by Linear Hash">
<!ENTITY title-partitioning-range "Partitioning by Range">
<!ENTITY title-partitioning-list "List Partitioning">
<!ENTITY title-partitioning-subpartitions "Subpartitioning">
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.3631) | jon | 27 Sep |
