List:Commits« Previous MessageNext Message »
From:jon.stephens Date:March 28 2011 1:53pm
Subject:svn commit - mysqldoc@oter02: r25584 - in trunk: dynamic-docs/changelog refman-5.6
View as plain text  
Author: js221926
Date: 2011-03-28 15:53:44 +0200 (Mon, 28 Mar 2011)
New Revision: 25584

Log:

Preliminary documentation for WL#5217 - Explicit partition selection



Modified:
   trunk/dynamic-docs/changelog/mysqld-2.xml
   trunk/refman-5.6/introduction.xml
   trunk/refman-5.6/partitioning.xml
   trunk/refman-5.6/sql-syntax-data-manipulation.xml


Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml	2011-03-27 00:29:44 UTC (rev 25583)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2011-03-28 13:53:44 UTC (rev 25584)
Changed blocks: 1, Lines Added: 51, Lines Deleted: 0; 2153 bytes

@@ -6,6 +6,57 @@
 ]>
 <changelog>
 
+  <logentry entrytype="feature">
+
+    <tags>
+      <highlight type="partitioning"/>
+      <manual type="partition selection"/>
+      <manual type="SELECT"/>
+      <manual type="DML"/>
+    </tags>
+
+    <bugs>
+      <fixes wlid="5217"/>
+    </bugs>
+
+    <versions>
+      <fixedin ver="5.6.2"/>
+    </versions>
+
+    <message>
+
+      <para>
+        It is now possible to select one or more partitions or
+        subpartitions when querying from a partitioned table. In
+        addition, many data modification statements
+        (<literal role="stmt">DELETE</literal>,
+        <literal role="stmt">INSERT</literal>,
+        <literal role="stmt">REPLACE</literal>,
+        <literal role="stmt">UPDATE</literal>, <literal role="stmt">LOAD
+        DATA</literal>, and <literal role="stmt">LOAD XML</literal>)
+        that act on partitioned tables also now support explicit
+        partition selection. For example, assume we have a table named
+        <literal>t</literal> with some integer column named
+        <literal>c</literal>, and <literal>t</literal> has 4 partitions
+        named <literal>p0</literal>, <literal>p1</literal>,
+        <literal>p2</literal>, and <literal>p3</literal>. Then the query
+        <literal role="stmt" condition="select">SELECT * FROM t
+        PARTITION (p0, p1) WHERE c &lt; 5</literal> returns rows only in
+        partitions <literal>p0</literal> and <literal>p1</literal> that
+        match the <literal>WHERE</literal> condition, while partitions
+        <literal>p2</literal> and <literal>p3</literal> are not checked.
+      </para>
+
+      <para>
+        For additional information and examples, see
+        <xref linkend="partitioning-selection"/>, as well as the
+        descriptions of the statements just listed.
+      </para>
+
+    </message>
+
+  </logentry>
+
   <logentry entrytype="bug">
 
     <tags>


Modified: trunk/refman-5.6/introduction.xml
===================================================================
--- trunk/refman-5.6/introduction.xml	2011-03-27 00:29:44 UTC (rev 25583)
+++ trunk/refman-5.6/introduction.xml	2011-03-28 13:53:44 UTC (rev 25584)
Changed blocks: 1, Lines Added: 72, Lines Deleted: 0; 2452 bytes

@@ -497,6 +497,78 @@
         </para>
       </listitem>
 
+      <listitem>
+        <para>
+          Explicit selection of one or more partitions or subpartitions
+          is now supported for queries, as well as for many data
+          modification statements, that act on partitioned tables. For
+          example, assume a table <literal>t</literal> with some integer
+          column <literal>c</literal> has 4 partitions named
+          <literal>p0</literal>, <literal>p1</literal>,
+          <literal>p2</literal>, and <literal>p3</literal>. Then the
+          query <literal>SELECT * FROM t PARTITION (p0, p1) WHERE c &lt;
+          5</literal> returns only those rows from partitions
+          <literal>p0</literal> and <literal>p1</literal> for which
+          <literal>c</literal> is less than 5.
+        </para>
+
+        <para>
+          The following statements support explicit partition selection:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal role="stmt">SELECT</literal>
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="stmt">DELETE</literal>
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="stmt">INSERT</literal>
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="stmt">REPLACE</literal>
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="stmt">UPDATE</literal>
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="stmt">LOAD DATA</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal role="stmt">LOAD XML</literal>.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          For syntax, see the descriptions of the individual statements.
+          For additional information and examples, see
+          <xref linkend="partitioning-selection"/>.
+        </para>
+      </listitem>
+
     </itemizedlist>
 
     <bridgehead>


Modified: trunk/refman-5.6/partitioning.xml
===================================================================
--- trunk/refman-5.6/partitioning.xml	2011-03-27 00:29:44 UTC (rev 25583)
+++ trunk/refman-5.6/partitioning.xml	2011-03-28 13:53:44 UTC (rev 25584)
Changed blocks: 2, Lines Added: 574, Lines Deleted: 0; 23509 bytes

@@ -455,6 +455,27 @@
           pruning</firstterm>. For more information, see
           <xref linkend="partitioning-pruning"/>.
         </para>
+
+        <para>
+          In addition, MySQL &current-series; supports explicit
+          partition selection for queries. For example,
+          <literal role="stmt" condition="select">SELECT * FROM t
+          PARTITION (p0,p1) WHERE c &lt; 5</literal> selects only those
+          rows in partitions <literal>p0</literal> and
+          <literal>p1</literal> that match the <literal>WHERE</literal>
+          condition. In this case, MySQL does not check any other
+          partitions of table <literal>t</literal>; this can greatly
+          speed up queries when you already know which partition or
+          partitions you wish to examine. Partition selection is also
+          supported for the data modification statements
+          <literal role="stmt">DELETE</literal>,
+          <literal role="stmt">INSERT</literal>,
+          <literal role="stmt">REPLACE</literal>,
+          <literal role="stmt">UPDATE</literal>, and
+          <literal role="stmt">LOAD DATA</literal>,
+          <literal role="stmt">LOAD XML</literal>. See the descriptions
+          of these statements for more information and examples.
+        </para>
       </listitem>
 
     </itemizedlist>

@@ -5955,6 +5976,559 @@
 
   </section>
 
+  <section id="partitioning-selection">
+
+    <title>Partition Selection</title>
+
+    <para>
+      MySQL 5.6 supports explicit selection of partitions and
+      subpartitions that, when executing a statement, should be checked
+      for rows matching a given <literal>WHERE</literal> condition.
+      Partition selection is similar to partition pruning, in that only
+      specific partitions are checked for matches, but differs in two
+      key respects:
+    </para>
+
+    <orderedlist>
+
+      <listitem>
+        <para>
+          The partitions to be checked are specified by the issuer of
+          the statement, unlike partition pruning, which is automatic.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          Whereas partition pruning applies only to queries, explicit
+          selection of partitions is supported for both queries and a
+          number of DML statements.
+        </para>
+      </listitem>
+
+    </orderedlist>
+
+    <para>
+      SQL statements supporting explicit partition selection are listed
+      here:
+    </para>
+
+    <itemizedlist>
+
+      <listitem>
+        <para>
+          <literal role="stmt">SELECT</literal>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal role="stmt">DELETE</literal>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal role="stmt">INSERT</literal>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal role="stmt">REPLACE</literal>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal role="stmt">UPDATE</literal>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal role="stmt">LOAD DATA</literal>.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
+          <literal role="stmt">LOAD XML</literal>.
+        </para>
+      </listitem>
+
+    </itemizedlist>
+
+    <para>
+      The remainder of this section discusses explicit partition
+      selection as it applies generally to the statements just listed,
+      and provides some examples.
+    </para>
+
+    <para>
+      Explicit partition selection is implemented using a
+      <literal>PARTITION</literal> option. For all supported statements,
+      this option uses the syntax shown here:
+    </para>
+
+<programlisting>
+      PARTITION (<replaceable>partition_names</replaceable>)
+
+      <replaceable>partition_names</replaceable>:
+          <replaceable>partition_name</replaceable>, ...
+</programlisting>
+
+    <para>
+      This option always follows the name of the table to which the
+      partition or partitions belong.
+      <replaceable>partition_names</replaceable> is a comma-separated
+      list of partitions or subpartitions to be used. Each name in this
+      list must be the name of an existing partition or subpartition of
+      the specified table; if any of the partitions or subpartitions are
+      not found, the statement fails with an error (<errortext>partition
+      '<replaceable>partition_name</replaceable>' doesn't
+      exist</errortext>). Partitions and subpartitions named in
+      <replaceable>partition_names</replaceable> may be listed in any
+      order, and may overlap.
+    </para>
+
+    <para>
+      When the <literal>PARTITION</literal> option is used, only the
+      partitions and subpartitions listed are checked for matching rows.
+      This option can be used in a <literal role="stmt">SELECT</literal>
+      statement to determine which rows belong to a given partition.
+      Consider a partitioned table named <literal>employees</literal>,
+      created and populated using the following two statements:
+    </para>
+
+<programlisting>
+CREATE TABLE employees  (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    fname VARCHAR(25) NOT NULL,
+    lname VARCHAR(25) NOT NULL,
+    store_id INT NOT NULL,
+    department_id INT NOT NULL
+)   
+    PARTITION BY RANGE(id)  (
+        PARTITION p0 VALUES LESS THAN (5),
+        PARTITION p1 VALUES LESS THAN (10),
+        PARTITION p2 VALUES LESS THAN (15),
+        PARTITION p3 VALUES LESS THAN MAXVALUE
+);
+
+INSERT INTO employees VALUES
+    ('', 'Bob', 'Taylor', 3, 2), ('', 'Frank', 'Williams', 1, 2), 
+    ('', 'Ellen', 'Johnson', 3, 4), ('', 'Jim', 'Smith', 2, 4),  
+    ('', 'Mary', 'Jones', 1, 1), ('', 'Linda', 'Black', 2, 3),
+    ('', 'Ed', 'Jones', 2, 1), ('', 'June', 'Wilson', 3, 1), 
+    ('', 'Andy', 'Smith', 1, 3), ('', 'Lou', 'Waters', 2, 4),  
+    ('', 'Jill', 'Stone', 1, 4), ('', 'Roger', 'White', 3, 2),
+    ('', 'Howard', 'Andrews', 1, 2), ('', 'Fred', 'Goldberg', 3, 3), 
+    ('', 'Barbara', 'Brown', 2, 3), ('', 'Alice', 'Rogers', 2, 2),  
+    ('', 'Mark', 'Morgan', 3, 3), ('', 'Karen', 'Cole', 3, 2);
+</programlisting>
+
+    <para>
+      You can see which rows are stored in partition
+      <literal>p1</literal> like this:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM employees PARTITION (p1);</userinput>
++----+-------+--------+----------+---------------+
+| id | fname | lname  | store_id | department_id |
++----+-------+--------+----------+---------------+
+|  5 | Mary  | Jones  |        1 |             1 |
+|  6 | Linda | Black  |        2 |             3 |
+|  7 | Ed    | Jones  |        2 |             1 |
+|  8 | June  | Wilson |        3 |             1 |
+|  9 | Andy  | Smith  |        1 |             3 |
++----+-------+--------+----------+---------------+
+5 rows in set (0.00 sec)
+</programlisting>
+
+    <para>
+      The result is the same as obtained by the query <literal>SELECT *
+      FROM employees WHERE id BETWEEN 5 AND 9</literal>.
+    </para>
+
+    <para>
+      To obtain rows from multiple partitions, supply their names as a
+      comma-delimited list. For example, <literal>SELECT * FROM
+      employees PARTITION (p1, p2)</literal> returns all rows from
+      partitions <literal>p1</literal> and <literal>p2</literal> while
+      excluding rows from the remaining partitions.
+    </para>
+
+    <para>
+      Any valid query against a partitioned table can be rewritten with
+      a <literal>PARTITION</literal> option to restrict the result to
+      one or more desired partitions. You can use
+      <literal>WHERE</literal> conditions, <literal>ORDER BY</literal>
+      and <literal>LIMIT</literal> options, and so on. You can also use
+      aggregate functions with <literal>HAVING</literal> and
+      <literal>GROUP BY</literal> options. Each of the following queries
+      produces a valid result when run on the
+      <literal>employees</literal> table as previously defined:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM employees PARTITION (p0, p2)</userinput>
+    -&gt;     <userinput>WHERE lname LIKE 'S%';</userinput>
++----+-------+-------+----------+---------------+
+| id | fname | lname | store_id | department_id |
++----+-------+-------+----------+---------------+
+|  4 | Jim   | Smith |        2 |             4 |
+| 11 | Jill  | Stone |        1 |             4 |
++----+-------+-------+----------+---------------+
+2 rows in set (0.00 sec)
+
+mysql&gt; <userinput>SELECT id, CONCAT(fname, ' ', lname) AS name</userinput> 
+    -&gt;     <userinput>FROM employees PARTITION (p0) ORDER BY lname;</userinput>
++----+----------------+
+| id | name           |
++----+----------------+
+|  3 | Ellen Johnson  |
+|  4 | Jim Smith      |
+|  1 | Bob Taylor     |
+|  2 | Frank Williams |
++----+----------------+
+4 rows in set (0.06 sec)
+
+mysql&gt; <userinput>SELECT store_id, COUNT(department_id) AS c</userinput> 
+    -&gt;     <userinput>FROM employees PARTITION (p1,p2,p3)</userinput> 
+    -&gt;     <userinput>GROUP BY store_id HAVING c &gt; 4;</userinput>
++---+----------+
+| c | store_id |
++---+----------+
+| 5 |        2 |
+| 5 |        3 |
++---+----------+
+2 rows in set (0.00 sec)
+</programlisting>
+
+    <para>
+      Statements using partition selection can be employed with tables
+      using any of the partitioning types supported in MySQL
+      &current-series;. When a table is created using <literal>[LINEAR]
+      HASH</literal> or <literal>[LINEAR] KEY</literal> partitioning and
+      the names of the partitions are not specified, MySQL automatically
+      names the partitions <literal>p0</literal>, <literal>p1</literal>,
+      <literal>p2</literal>, ...,
+      <literal>p<replaceable>N-1</replaceable></literal>, where
+      <replaceable>N</replaceable> is the number of partitions.
+      Subpartitions not explicitly named, MySQL automatically to the
+      subpartitions in each partition
+      <literal>p<replaceable>X</replaceable></literal> the names
+      <literal>p<replaceable>X</replaceable>sp0</literal>,
+      <literal>p<replaceable>X</replaceable>sp1</literal>,
+      <literal>p<replaceable>X</replaceable>sp2</literal>, ...,
+      <literal>p<replaceable>X</replaceable>sp<replaceable>M-1</replaceable></literal>,
+      where <replaceable>M</replaceable> is the number of subpartitions.
+      You can use these generated names in the
+      <literal>PARTITION</literal> option of a
+      <literal role="stmt">SELECT</literal> (or other SQL statement for
+      which explicit partition is allowed) run against this table. as
+      shown here:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE employees_sub  (</userinput>
+    -&gt;     <userinput>id INT NOT NULL AUTO_INCREMENT,</userinput>
+    -&gt;     <userinput>fname VARCHAR(25) NOT NULL,</userinput>
+    -&gt;     <userinput>lname VARCHAR(25) NOT NULL,</userinput>
+    -&gt;     <userinput>store_id INT NOT NULL,</userinput>
+    -&gt;     <userinput>department_id INT NOT NULL,</userinput>
+    -&gt;     <userinput>PRIMARY KEY pk (id, lname)</userinput>
+    -&gt; <userinput>)</userinput>   
+    -&gt;     <userinput>PARTITION BY RANGE(id)</userinput>
+    -&gt;     <userinput>SUBPARTITION BY KEY (lname)</userinput>
+    -&gt;     <userinput>SUBPARTITIONS 2 (</userinput>
+    -&gt;         <userinput>PARTITION p0 VALUES LESS THAN (5),</userinput>
+    -&gt;         <userinput>PARTITION p1 VALUES LESS THAN (10),</userinput>
+    -&gt;         <userinput>PARTITION p2 VALUES LESS THAN (15),</userinput>
+    -&gt;         <userinput>PARTITION p3 VALUES LESS THAN MAXVALUE</userinput>
+    -&gt; <userinput>);</userinput>
+Query OK, 0 rows affected (1.14 sec)
+
+mysql&gt; <userinput>INSERT INTO employees_sub</userinput>   # re-use data in employees table
+    -&gt;     <userinput>SELECT * FROM employees;</userinput>
+Query OK, 18 rows affected (0.09 sec)
+Records: 18  Duplicates: 0  Warnings: 0
+
+mysql&gt; <userinput>SELECT id, CONCAT(fname, ' ', lname) AS name</userinput>
+    -&gt;     <userinput>FROM employees_sub PARTITION (p2sp1);</userinput>
++----+---------------+
+| id | name          |
++----+---------------+
+| 10 | Lou Waters    |
+| 14 | Fred Goldberg |
++----+---------------+
+2 rows in set (0.00 sec)
+</programlisting>
+
+    <para>
+      You may also use a <literal>PARTITION</literal> option in the
+      <literal role="stmt">SELECT</literal> portion of an
+      <literal role="stmt" condition="insert-select">INSERT ...
+      SELECT</literal> statement, as shown here:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE employees_copy LIKE employees;</userinput>
+Query OK, 0 rows affected (0.28 sec)
+
+mysql&gt; <userinput>INSERT INTO employees_copy</userinput> 
+    -&gt;     <userinput>SELECT * FROM employees PARTITION (p2);</userinput>
+Query OK, 5 rows affected (0.04 sec)
+Records: 5  Duplicates: 0  Warnings: 0
+
+mysql&gt; <userinput>SELECT * FROM employees_copy;</userinput>
++----+--------+----------+----------+---------------+
+| id | fname  | lname    | store_id | department_id |
++----+--------+----------+----------+---------------+
+| 10 | Lou    | Waters   |        2 |             4 |
+| 11 | Jill   | Stone    |        1 |             4 |
+| 12 | Roger  | White    |        3 |             2 |
+| 13 | Howard | Andrews  |        1 |             2 |
+| 14 | Fred   | Goldberg |        3 |             3 |
++----+--------+----------+----------+---------------+
+5 rows in set (0.00 sec)
+</programlisting>
+
+    <para>
+      Partition selection can also be used with joins. Suppose we create
+      and populate two tables using the statements shown here:
+    </para>
+
+<programlisting>
+CREATE TABLE stores (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    city VARCHAR(30) NOT NULL
+)
+    PARTITION BY HASH(id)
+    PARTITIONS 2;
+    
+INSERT INTO stores VALUES
+    ('', 'Nambucca'), ('', 'Uranga'), 
+    ('', 'Bellingen'), ('', 'Grafton');
+    
+CREATE TABLE departments  (
+    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
+    name VARCHAR(30) NOT NULL
+)
+    PARTITION BY KEY(id)
+    PARTITIONS 2;
+    
+INSERT INTO departments VALUES
+    ('', 'Sales'), ('', 'Customer Service'), 
+    ('', 'Delivery'), ('', 'Accounting');
+</programlisting>
+
+    <para>
+      You can explicitly select partitions (or subpartitions, opr both)
+      from any or all of the tables in a join. (Note that the
+      <literal>PARTITION</literal> option used to select partitions from
+      a given table immediately follows the name of the table, before
+      all other options, including any table alias.) For example, the
+      following query gets the name, employee ID, department, and city
+      of all employees who work in the Sales or Delivery department
+      (partition <literal>p1</literal> of the
+      <literal>departments</literal> table) at the stores in either of
+      the cities of Nambucca and Bellingen (partition
+      <literal>p0</literal> of the <literal>stores</literal> table):
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT</userinput>
+    -&gt;     <userinput>e.id AS 'Employee ID', CONCAT(e.fname, ' ', e.lname) AS Name,</userinput>
+    -&gt;     <userinput>s.city AS City, d.name AS department</userinput>
+    -&gt; <userinput>FROM employees AS e</userinput>
+    -&gt;     <userinput>JOIN stores PARTITION (p1) AS s ON e.store_id=s.id</userinput>
+    -&gt;     <userinput>JOIN departments PARTITION (p0) AS d ON e.department_id=d.id</userinput>
+    -&gt; <userinput>ORDER BY e.lname;</userinput>
++-------------+---------------+-----------+------------+
+| Employee ID | Name          | City      | department |
++-------------+---------------+-----------+------------+
+|          14 | Fred Goldberg | Bellingen | Delivery   |
+|           5 | Mary Jones    | Nambucca  | Sales      |
+|          17 | Mark Morgan   | Bellingen | Delivery   |
+|           9 | Andy Smith    | Nambucca  | Delivery   |
+|           8 | June Wilson   | Bellingen | Sales      |
++-------------+---------------+-----------+------------+
+5 rows in set (0.00 sec)
+</programlisting>
+
+    <para>
+      For general information about joins in MySQL, see
+      <xref linkend="join"/>.
+    </para>
+
+    <para>
+      When the <literal>PARTITION</literal> option is used with
+      <literal role="stmt">DELETE</literal> statements, only those
+      partitions (and subpartitions, if any) listed with the option are
+      checked for rows to be deleted. Any other partitions are ignored,
+      as shown here:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM employees WHERE fname LIKE 'j%';</userinput>
++----+-------+--------+----------+---------------+
+| id | fname | lname  | store_id | department_id |
++----+-------+--------+----------+---------------+
+|  4 | Jim   | Smith  |        2 |             4 |
+|  8 | June  | Wilson |        3 |             1 |
+| 11 | Jill  | Stone  |        1 |             4 |
++----+-------+--------+----------+---------------+
+3 rows in set (0.00 sec)
+
+mysql&gt; <userinput>DELETE FROM employees PARTITION (p0, p1)</userinput> 
+    -&gt;     <userinput>WHERE fname LIKE 'j%';</userinput>
+Query OK, 2 rows affected (0.09 sec)
+
+mysql&gt; <userinput>SELECT * FROM employeesh WHERE fname LIKE 'j%';</userinput>
++----+-------+-------+----------+---------------+
+| id | fname | lname | store_id | department_id |
++----+-------+-------+----------+---------------+
+| 11 | Jill  | Stone |        1 |             4 |
++----+-------+-------+----------+---------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+    <para>
+      Only the two rows in partitions <literal>p0</literal> and
+      <literal>p1</literal> matching the <literal>WHERE</literal>
+      condition were deleted. As you can see from the result when the
+      <literal role="stmt">SELECT</literal> is run a second time, there
+      remains a row in the table matching the <literal>WHERE</literal>
+      condition, but residing in a different partition
+      (<literal>p2</literal>).
+    </para>
+
+    <para>
+      <literal role="stmt">UPDATE</literal> statements using explicit
+      partition selection behave in the same way; only rows in the
+      partitions referenced by the <literal>PARTITION</literal> option
+      are considered when determining the rows to be updated, as can be
+      seen by executing the following statements:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>UPDATE employees PARTITION (p0) </userinput>
+    -&gt;     <userinput>SET store_id = 2 WHERE fname = 'Jill';</userinput>
+Query OK, 0 rows affected (0.00 sec)
+Rows matched: 0  Changed: 0  Warnings: 0
+
+mysql&gt; <userinput>SELECT * FROM employees WHERE fname = 'Jill';</userinput>
++----+-------+-------+----------+---------------+
+| id | fname | lname | store_id | department_id |
++----+-------+-------+----------+---------------+
+| 11 | Jill  | Stone |        1 |             4 |
++----+-------+-------+----------+---------------+
+1 row in set (0.00 sec)
+
+mysql&gt; <userinput>UPDATE employees PARTITION (p2)</userinput>
+    -&gt;     <userinput>SET store_id = 2 WHERE fname = 'Jill';</userinput>
+Query OK, 1 row affected (0.09 sec)
+Rows matched: 1  Changed: 1  Warnings: 0
+
+mysql&gt; <userinput>SELECT * FROM employees WHERE fname = 'Jill';</userinput>
++----+-------+-------+----------+---------------+
+| id | fname | lname | store_id | department_id |
++----+-------+-------+----------+---------------+
+| 11 | Jill  | Stone |        2 |             4 |
++----+-------+-------+----------+---------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+    <para>
+      In the same way, when <literal>PARTITION</literal> is used with
+      <literal role="stmt">DELETE</literal>, only rows in the partition
+      or partitions named in the partition list are checked for
+      deletion.
+    </para>
+
+    <para>
+      For statements that insert rows, the behavior differs in that
+      failure to find a suitable partition causes the statement to fail.
+      This is true for both <literal role="stmt">INSERT</literal> and
+      <literal role="stmt">REPLACE</literal> statements, as shown here:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>INSERT INTO employees PARTITION (p2) VALUES (20, 'Jan', 'Jones', 1, 3);</userinput>
+<errortext>ERROR 1729 (HY000): Found a row not matching the given partition set</errortext>
+mysql&gt; <userinput>INSERT INTO employees PARTITION (p3) VALUES (20, 'Jan', 'Jones', 1, 3);</userinput>
+Query OK, 1 row affected (0.07 sec)
+
+mysql&gt; REPLACE INTO employees PARTITION (p0) VALUES (20, 'Jan', 'Jones', 3, 2);
+<errortext>ERROR 1729 (HY000): Found a row not matching the given partition set</errortext>
+
+mysql&gt; REPLACE INTO employees PARTITION (p3) VALUES (20, 'Jan', 'Jones', 3, 2);
+Query OK, 2 rows affected (0.09 sec)
+</programlisting>
+
+    <para>
+      For statements that write multiple rows, if any row in the list
+      following <literal>VALUES</literal> cannot be written to one of
+      the partitions specified in the
+      <replaceable>partition_names</replaceable> list, the entire
+      statement fails and no rows are written. This is shown for
+      <literal role="stmt">INSERT</literal> statements in the following
+      example, reusing the <literal>employees</literal> table created
+      previously:
+    </para>
+
+<programlisting>
+mysql&gt; <userinput>ALTER TABLE employees</userinput>
+    -&gt;     <userinput>REORGANIZE PARTITION p3 INTO (</userinput>
+    -&gt;         <userinput>PARTITION p3 VALUES LESS THAN (20),</userinput>
+    -&gt;         <userinput>PARTITION p4 VALUES LESS THAN (25),</userinput>
+    -&gt;         <userinput>PARTITION p5 VALUES LESS THAN MAXVALUE</userinput>
+    -&gt;     <userinput>);</userinput>
+Query OK, 6 rows affected (2.09 sec)
+Records: 6  Duplicates: 0  Warnings: 0
+
+mysql&gt; <userinput>SHOW CREATE TABLE employees\G</userinput>
+*************************** 1. row ***************************
+       Table: employees
+Create Table: CREATE TABLE `employees` (
+  `id` int(11) NOT NULL AUTO_INCREMENT,
+  `fname` varchar(25) NOT NULL,
+  `lname` varchar(25) NOT NULL,
+  `store_id` int(11) NOT NULL,
+  `department_id` int(11) NOT NULL,
+  PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=27 DEFAULT CHARSET=latin1
+/*!50100 PARTITION BY RANGE (id)
+(PARTITION p0 VALUES LESS THAN (5) ENGINE = InnoDB,
+ PARTITION p1 VALUES LESS THAN (10) ENGINE = InnoDB,
+ PARTITION p2 VALUES LESS THAN (15) ENGINE = InnoDB,
+ PARTITION p3 VALUES LESS THAN (20) ENGINE = InnoDB,
+ PARTITION p4 VALUES LESS THAN (25) ENGINE = InnoDB,
+ PARTITION p5 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
+1 row in set (0.00 sec)
+
+mysql&gt; <userinput>INSERT INTO employees PARTITION (p3, p4) VALUES</userinput> 
+    -&gt;     <userinput>(24, 'Tim', 'Greene', 3, 1),  (26, 'Linda', 'Mills', 2, 1);</userinput>
+ERROR 1729 (HY000): Found a row not matching the given partition set
+
+mysql&gt; <userinput>INSERT INTO employees PARTITION (p3, p4. p5) VALUES</userinput> 
+    -&gt;     <userinput>(24, 'Tim', 'Greene', 3, 1),  (26, 'Linda', 'Mills', 2, 1);</userinput>
+Query OK, 2 rows affected (0.06 sec)
+Records: 2  Duplicates: 0  Warnings: 0
+</programlisting>
+
+    <para>
+      The preceding is true for both
+      <literal role="stmt">INSERT</literal> statements and
+      <literal role="stmt">REPLACE</literal> statements that write
+      multiple rows.
+    </para>
+
+  </section>
+
   <section id="partitioning-limitations">
 
     <title>Restrictions and Limitations on Partitioning</title>


Modified: trunk/refman-5.6/sql-syntax-data-manipulation.xml
===================================================================
--- trunk/refman-5.6/sql-syntax-data-manipulation.xml	2011-03-27 00:29:44 UTC (rev 25583)
+++ trunk/refman-5.6/sql-syntax-data-manipulation.xml	2011-03-28 13:53:44 UTC (rev 25584)
Changed blocks: 24, Lines Added: 191, Lines Deleted: 21; 16891 bytes

@@ -253,6 +253,7 @@
 
     <remark role="help-keywords">
       DELETE BY ORDER LIMIT WHERE FROM USING LOW_PRIORITY QUICK
+      PARTITION
     </remark>
 
     <remark role="help-syntax-begin"/>

@@ -263,6 +264,7 @@
 
 <programlisting>
 DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM <replaceable>tbl_name</replaceable>
+    [PARTITION (<replaceable>partition_name</replaceable>,...)]
     [WHERE <replaceable>where_condition</replaceable>]
     [ORDER BY ...]
     [LIMIT <replaceable>row_count</replaceable>]

@@ -349,6 +351,44 @@
       <xref linkend="lock-tables"/>.
     </para>
 
+    <para>
+      Beginning with MySQL 5.6.2, <literal>DELETE</literal> supports
+      explicit partition selection using the
+      <literal>PARTITION</literal> option, which takes a comma-separated
+      list of the names of one or more partitions or subpartitions (or
+      both) from which to select rows to be dropped. Partitions not
+      included in the list are ignored. Given a partitioned table
+      <literal>t</literal> with a partition named <literal>p0</literal>,
+      executing the statement <literal>DELETE FROM t PARTITION
+      (p0)</literal> has the same effect on the table as executing
+      <literal role="stmt" condition="alter-table">ALTER TABLE t
+      TRUNCATE PARTITION (p0)</literal>; in both cases, all rows in
+      partition <literal>p0</literal> are dropped.
+    </para>
+
+    <para>
+      <literal>PARTITION</literal> can be used along with a
+      <literal>WHERE</literal> condition, in which case the condition is
+      tested only on rows in the listed partitions. For example,
+      <literal>DELETE FROM t PARTITION (p0) WHERE c &lt; 5</literal>
+      deletes rows only from partition <literal>p0</literal> for which
+      the condition <literal>c &lt; 5</literal> is true; rows in any
+      other partitions are not checked and thus not affected by the
+      <literal>DELETE</literal>.
+    </para>
+
+    <para>
+      The <literal>PARTITION</literal> option can also be used in
+      multiple-table <literal>DELETE</literal> statements. You can use
+      up to one such option per table named in the
+      <literal>FROM</literal> option.
+    </para>
+
+    <para>
+      See <xref linkend="partitioning-selection"/>, for more information
+      and examples.
+    </para>
+
     <remark role="help-description-end"/>
 
     <para>

@@ -1001,14 +1041,15 @@
 
     <remark role="help-keywords">
       INSERT INTO LOW_PRIORITY HIGH_PRIORITY IGNORE DUPLICATE KEY UPDATE
-      DELAYED DEFAULT VALUES VALUE SELECT SET
+      DELAYED DEFAULT VALUES VALUE SELECT SET PARTITION
     </remark>
 
     <remark role="help-syntax-begin"/>
 
 <programlisting>
 INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
-    [INTO] <replaceable>tbl_name</replaceable> [(<replaceable>col_name</replaceable>,...)]
+    [INTO] <replaceable>tbl_name</replaceable> [PARTITION (<replaceable>partition_name</replaceable>,...)] 
+    [(<replaceable>col_name</replaceable>,...)]
     {VALUES | VALUE} ({<replaceable>expr</replaceable> | DEFAULT},...),(...),...
     [ ON DUPLICATE KEY UPDATE
       <replaceable>col_name</replaceable>=<replaceable>expr</replaceable>

@@ -1021,7 +1062,7 @@
 
 <programlisting>
 INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
-    [INTO] <replaceable>tbl_name</replaceable>
+    [INTO] <replaceable>tbl_name</replaceable> [PARTITION (<replaceable>partition_name</replaceable>,...)]
     SET <replaceable>col_name</replaceable>={<replaceable>expr</replaceable> | DEFAULT}, ...
     [ ON DUPLICATE KEY UPDATE
       <replaceable>col_name</replaceable>=<replaceable>expr</replaceable>

@@ -1034,7 +1075,8 @@
 
 <programlisting>
 INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
-    [INTO] <replaceable>tbl_name</replaceable> [(<replaceable>col_name</replaceable>,...)]
+    [INTO] <replaceable>tbl_name</replaceable> [PARTITION (<replaceable>partition_name</replaceable>,...)] 
+    [(<replaceable>col_name</replaceable>,...)]
     SELECT ...
     [ ON DUPLICATE KEY UPDATE
       <replaceable>col_name</replaceable>=<replaceable>expr</replaceable>

@@ -1058,6 +1100,20 @@
       <xref linkend="insert-select"/>.
     </para>
 
+    <para>
+      In MySQL 5.6.2 and later, when inserting into a partitioned table,
+      you can control which partitions and subpartitions accept new
+      rows. The <literal>PARTITION</literal> option takes a
+      comma-separated list of the names of one or more partitions or
+      subpartitions (or both) of the table. If any of the rows to be
+      inserted by a given <literal>INSERT</literal> statement do not
+      match one of the partitions listed, the <literal>INSERT</literal>
+      statement fails with the error <errortext>Found a row not matching
+      the given partition set</errortext>. See
+      <xref linkend="partitioning-selection"/>, for more information and
+      examples.
+    </para>
+
     <remark role="help-description-end"/>
 
     <para>

@@ -1578,7 +1634,9 @@
 
 <programlisting>
 INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
-    [INTO] <replaceable>tbl_name</replaceable> [(<replaceable>col_name</replaceable>,...)]
+    [INTO] <replaceable>tbl_name</replaceable> 
+    [PARTITION (<replaceable>partition_name</replaceable>,...)]
+    [(<replaceable>col_name</replaceable>,...)]
     SELECT ...
     [ ON DUPLICATE KEY UPDATE <replaceable>col_name</replaceable>=<replaceable>expr</replaceable>, ... ]
 </programlisting>

@@ -1676,6 +1734,24 @@
       </itemizedlist>
 
       <para>
+        Starting with MySQL 5.6.2, you can explicitly select which
+        partitions or subpartitions (or both) of the source or target
+        table (or both) are to be used with a
+        <literal>PARTITION</literal> option following the name of the
+        table. When <literal>PARTITION</literal> is used with the name
+        of the source table in the <literal role="stmt">SELECT</literal>
+        portion of the statement, rows are selected only from the
+        partitions or subpartitions named in its partition list. When
+        <literal>PARTITION</literal> is used with the name of the target
+        table for the <literal role="stmt">INSERT</literal> portion of
+        the statement, then it must be possible to insert all rows
+        selected into the partitions or subpartitions named in the
+        partition list following the option, else the <literal>INSERT
+        ... SELECT</literal> statement fails. For more information and
+        examples, see <xref linkend="partitioning-selection"/>.
+      </para>
+
+      <para>
         In the values part of <literal>ON DUPLICATE KEY
         UPDATE</literal>, you can refer to columns in other tables, as
         long as you do not use <literal>GROUP BY</literal> in the

@@ -2219,7 +2295,7 @@
     <remark role="help-keywords">
       BY LOAD DATA LOW_PRIORITY CONCURRENT LOCAL INFILE REPLACE IGNORE
       FIELDS COLUMNS ENCLOSED TERMINATED ESCAPED LINES IMPORT CSV
-      OPTIONALLY STARTING CHARACTER SET
+      OPTIONALLY STARTING CHARACTER SET PARTITION
     </remark>
 
     <remark role="help-syntax"/>

@@ -2228,6 +2304,7 @@
 LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE '<replaceable>file_name</replaceable>'
     [REPLACE | IGNORE]
     INTO TABLE <replaceable>tbl_name</replaceable>
+    [PARTITION (<replaceable>partition_name</replaceable>,...)]
     [CHARACTER SET <replaceable>charset_name</replaceable>]
     [{FIELDS | COLUMNS}
         [TERMINATED BY '<replaceable>string</replaceable>']

@@ -2445,6 +2522,18 @@
     </para>
 
     <para>
+      In MySQL 5.6.2 and later, <literal>LOAD DATA</literal> supports
+      explicit partition selection using the
+      <literal>PARTITION</literal> option with a comma-separated list of
+      more or more names of partitions, subpartitions, or both. When
+      this option is used, if any rows from the file cannot be inserted
+      into any of the partitions or subpartitions named in the list, the
+      statement fails with the error <errortext>Found a row not matching
+      the given partition set</errortext>. For more information, see
+      <xref linkend="partitioning-selection"/>.
+    </para>
+
+    <para>
       For security reasons, when reading text files located on the
       server, the files must either reside in the database directory or
       be readable by all. Also, to use

@@ -3562,21 +3651,21 @@
     <remark role="help-topic" condition="LOAD XML"/>
 
     <remark role="help-keywords">
-      LOW_PRIORITY CONCURRENT LOCAL INFILE REPLACE IGNORE CHARACTER SET
-      ROWS IDENTIFIED BY LINES
+      LOW_PRIORITY CONCURRENT LOCAL INFILE REPLACE IGNORE PARTITION
+      CHARACTER SET ROWS IDENTIFIED BY LINES
     </remark>
 
     <remark role="help-syntax-begin"/>
 
 <programlisting>
-LOAD XML [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE '<replaceable>file_name</replaceable>'
-[REPLACE | IGNORE]
-INTO TABLE [<replaceable>db_name</replaceable>.]<replaceable>tbl_name</replaceable>
-[CHARACTER SET <replaceable>charset_name</replaceable>]
-[ROWS IDENTIFIED BY '&lt;<replaceable>tagname</replaceable>&gt;']
-[IGNORE <replaceable>number</replaceable> [LINES | ROWS]]
-[(<replaceable>column_or_user_var</replaceable>,...)]
-[SET <replaceable>col_name</replaceable> = <replaceable>expr</replaceable>,...]
+LOAD XML [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE '<replaceable>file_name</replaceable>' [REPLACE | IGNORE]
+    INTO TABLE [<replaceable>db_name</replaceable>.]<replaceable>tbl_name</replaceable>
+    [PARTITION (<replaceable>partition_name</replaceable>,...)]
+    [CHARACTER SET <replaceable>charset_name</replaceable>]
+    [ROWS IDENTIFIED BY '&lt;<replaceable>tagname</replaceable>&gt;']
+    [IGNORE <replaceable>number</replaceable> [LINES | ROWS]]
+    [(<replaceable>column_or_user_var</replaceable>,...)]
+    [SET <replaceable>col_name</replaceable> = <replaceable>expr</replaceable>,...]
 </programlisting>
 
     <remark role="help-syntax-end"/>

@@ -3705,6 +3794,12 @@
 
       <listitem>
         <para>
+          <literal>PARTITION</literal>
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           <literal>CHARACTER SET</literal>
         </para>
       </listitem>

@@ -4166,14 +4261,17 @@
     <remark role="help-topic" condition="REPLACE"/>
 
     <remark role="help-keywords">
-      REPLACE DELAYED LOW_PRIORITY INTO VALUES VALUE SELECT SET DEFAULT
+      REPLACE DELAYED LOW_PRIORITY INTO PARTITION VALUES VALUE SELECT
+      SET DEFAULT
     </remark>
 
     <remark role="help-syntax-begin"/>
 
 <programlisting>
 REPLACE [LOW_PRIORITY | DELAYED]
-    [INTO] <replaceable>tbl_name</replaceable> [(<replaceable>col_name</replaceable>,...)]
+    [INTO] <replaceable>tbl_name</replaceable>
+    [PARTITION (<replaceable>partition_name</replaceable>,...)] 
+    [(<replaceable>col_name</replaceable>,...)]
     {VALUES | VALUE} ({<replaceable>expr</replaceable> | DEFAULT},...),(...),...
 </programlisting>
 

@@ -4184,6 +4282,7 @@
 <programlisting>
 REPLACE [LOW_PRIORITY | DELAYED]
     [INTO] <replaceable>tbl_name</replaceable>
+    [PARTITION (<replaceable>partition_name</replaceable>,...)] 
     SET <replaceable>col_name</replaceable>={<replaceable>expr</replaceable> | DEFAULT}, ...
 </programlisting>
 

@@ -4193,7 +4292,9 @@
 
 <programlisting>
 REPLACE [LOW_PRIORITY | DELAYED]
-    [INTO] <replaceable>tbl_name</replaceable> [(<replaceable>col_name</replaceable>,...)]
+    [INTO] <replaceable>tbl_name</replaceable>
+    [PARTITION (<replaceable>partition_name</replaceable>,...)]  
+    [(<replaceable>col_name</replaceable>,...)]
     SELECT ...
 </programlisting>
 

@@ -4250,6 +4351,19 @@
       <literal role="priv">DELETE</literal> privileges for the table.
     </para>
 
+    <para>
+      Beginning with MySQL 5.6.2, <literal>REPLACE</literal> supports
+      explicit partition selection using the
+      <literal>PARTITION</literal> option with a comma-separated list of
+      names of partitions, subpartitions, or both. As with
+      <literal role="stmt">INSERT</literal>, if it is not possible to
+      insert the new row into any of these partitions or subpartitions,
+      the <literal>REPLACE</literal> statement fails with the error
+      <errortext>Found a row not matching the given partition
+      set</errortext>. See <xref linkend="partitioning-selection"/>, for
+      more information.
+    </para>
+
     <remark role="help-description-end"/>
 
     <para>

@@ -4351,6 +4465,7 @@
       SQL_NO_CACHE SQL_CALC_FOUND_ROWS HIGH_PRIORITY DISTINCT
       DISTINCTROW ALL INTO FROM OUTFILE DUMPFILE IGNORE JOIN LOCK IN
       SHARE MODE FOR UPDATE OFFSET LIMIT MEMORY PROCEDURE CHARACTER SET
+      PARTITION
     </remark>
 
     <remark role="help-syntax"/>

@@ -4414,6 +4529,20 @@
 
       <listitem>
         <para>
+          Starting in MySQL 5.6.2, <literal>SELECT</literal> supports
+          explicit partition selection using the
+          <literal>PARTITION</literal> with a list of partitions or
+          subpartitions (or both) following the name of the table in a
+          <replaceable>table_reference</replaceable> (see
+          <xref linkend="join"/>). In this case, rows are selected only
+          from the partitions listed, and any other partitions of the
+          table are ignored. For more information and examples, see
+          <xref linkend="partitioning-selection"/>.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           The <literal>WHERE</literal> clause, if given, indicates the
           condition or conditions that rows must satisfy to be selected.
           <replaceable>where_condition</replaceable> is an expression

@@ -5605,7 +5734,7 @@
 
       <remark role="help-keywords">
         JOIN INNER CROSS LEFT OUTER NATURAL RIGHT STRAIGHT_JOIN USE
-        INDEX AS IGNORE FORCE ON USING
+        INDEX AS IGNORE FORCE ON USING PARTITION
       </remark>
 
       <remark role="help-description-begin"/>

@@ -5627,7 +5756,8 @@
   | <replaceable>join_table</replaceable>
 
 <replaceable>table_factor</replaceable>:
-    <replaceable>tbl_name</replaceable> [[AS] <replaceable>alias</replaceable>] [<replaceable>index_hint_list</replaceable>]
+    <replaceable>tbl_name</replaceable> [PARTITION (<replaceable>partition_names</replaceable>)] 
+        [[AS] <replaceable>alias</replaceable>] [<replaceable>index_hint_list</replaceable>]
   | <replaceable>table_subquery</replaceable> [AS] <replaceable>alias</replaceable>
   | ( <replaceable>table_references</replaceable> )
   | { OJ <replaceable>table_reference</replaceable> LEFT OUTER JOIN <replaceable>table_reference</replaceable>

@@ -5664,6 +5794,18 @@
       </para>
 
       <para>
+        In MySQL 5.6.2 and later, a table reference (when it refers to a
+        partitioned table) may contain a <literal>PARTITION</literal>
+        option, including a comma-separated list of partitions,
+        subpartitions, or both. This option follows the name of the
+        table and precedes any alias declaration. The effect of this
+        option is that rows are selected only from the listed partitions
+        or subpartitions&mdash;in other words, any partitions or
+        subpartitions not named in the list are ignored For more
+        information, see <xref linkend="partitioning-selection"/>.
+      </para>
+
+      <para>
         The syntax of <replaceable>table_factor</replaceable> is
         extended in comparison with the SQL Standard. The latter accepts
         only <replaceable>table_reference</replaceable>, not a list of

@@ -8676,6 +8818,34 @@
     </para>
 
     <para>
+      For partitioned tables, both the single-single and multiple-table
+      forms of this statement support the use of a
+      <literal>PARTITION</literal> option as part of a table reference.
+      This option takes a list of one or more partitions or
+      subpartitions (or both). Only the partitions (or subpartitions)
+      listed are checked for matches, and a row that is not in any of
+      these partitions or subpartitions is not updated, whether it
+      satisfies the <replaceable>where_condition</replaceable> or not.
+    </para>
+
+    <note>
+      <para>
+        Unlike the case when using <literal>PARTITION</literal> with an
+        <literal role="stmt">INSERT</literal> or
+        <literal role="stmt">REPLACE</literal> statement, an otherwise
+        valid <literal>UPDATE ... PARTITION</literal> statement is
+        considered successful even if no rows in the listed partitions
+        (or subpartitions) match the
+        <replaceable>where_condition</replaceable>.
+      </para>
+    </note>
+
+    <para>
+      See <xref linkend="partitioning-selection"/>, for more information
+      and examples.
+    </para>
+
+    <para>
       <replaceable>where_condition</replaceable> is an expression that
       evaluates to true for each row to be updated. For expression
       syntax, see <xref linkend="expressions"/>.


Thread
svn commit - mysqldoc@oter02: r25584 - in trunk: dynamic-docs/changelog refman-5.6jon.stephens28 Mar