List:Commits« Previous MessageNext Message »
From:paul Date:January 16 2006 2:42am
Subject:svn commit - mysqldoc@docsrva: r847 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-16 03:42:43 +0100 (Mon, 16 Jan 2006)
New Revision: 847

Log:
 r6239@frost:  paul | 2006-01-15 19:49:29 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/optimization.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.1/client-utility-programs.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-common/news-5.1.xml
   trunk/refman-common/titles.en.ent


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6238
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6239
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-4.1/database-administration.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -20148,21 +20148,13 @@
       </para>
 
       <para>
-        To change the error message file, you should edit the
-        <filename>errmsg.txt</filename> file, and then execute the
-        following command to generate the
-        <filename>errmsg.sys</filename> file:
+         You can also change the error messages produced by the server.
+         Details can be found in the MySQL Internals manual, available at
+         <ulink url="&base-url-docs;"/>. If you upgrade to a newer
+         version of MySQL after changing the error messages, remember to
+         repeat your changes after the upgrade.
       </para>
 
-<programlisting>
-shell&gt; <userinput>comp_err errmsg.txt errmsg.sys</userinput>
-</programlisting>
-
-      <para>
-        When you upgrade to a newer version of MySQL, remember to repeat
-        your changes with the new <filename>errmsg.txt</filename> file.
-      </para>
-
     </section>
 
     <section id="adding-character-set">

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-4.1/optimization.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -235,7 +235,7 @@
       <para>
         If you strive for database independence, you need to get a good
         feeling for each SQL server's bottlenecks. For example, MySQL is
-        very fast in retrieving and updating records for
+        very fast in retrieving and updating rows for
         <literal>MyISAM</literal> tables, but has a problem in mixing
         slow readers and writers on the same table. Oracle, on the other
         hand, has a big problem when you try to access rows that you
@@ -258,7 +258,7 @@
         system (such as the <literal>REPLACE</literal> statement, which
         is specific to MySQL), you should implement the same feature for
         other SQL servers by coding an alternative method. Although the
-        alternative might be slower, it allows the other servers to
+        alternative might be slower, it enables the other servers to
         perform the same tasks.
       </para>
 
@@ -534,13 +534,12 @@
 
       <para>
         You should definitely benchmark your application and database to
-        find out where the bottlenecks are. By fixing a bottleneck (or
-        by replacing it with a <quote>dummy</quote> module), you can
-        then proceed to identify the next bottleneck. Even if the
-        overall performance for your application currently is
-        acceptable, you should at least make a plan for each bottleneck
-        and decide how to solve it if someday you really need the extra
-        performance.
+        find out where the bottlenecks are. After fixing one bottleneck
+        (or by replacing it with a <quote>dummy</quote> module), you can
+        proceed to identify the next bottleneck. Even if the overall
+        performance for your application currently is acceptable, you
+        should at least make a plan for each bottleneck and decide how
+        to solve it if someday you really need the extra performance.
       </para>
 
       <para>
@@ -575,8 +574,8 @@
         benchmarking your whole application under the worst possible
         load. You can use Super Smack, available at
         <ulink url="http://jeremy.zawodny.com/mysql/super-smack/"/>. As
-        suggested by its name, it can bring a system to its knees if you
-        ask it, so make sure to use it only on your development systems.
+        suggested by its name, it can bring a system to its knees, so
+        make sure to use it only on your development systems.
       </para>
 
     </section>
@@ -713,9 +712,11 @@
         <listitem>
           <para>
             When you precede a <literal>SELECT</literal> statement with
-            the keyword <literal>EXPLAIN</literal>, MySQL explains how
-            it would process the <literal>SELECT</literal>, providing
-            information about how tables are joined and in which order.
+            the keyword <literal>EXPLAIN</literal>, MySQL displays
+            information from the optimizer about the query execution
+            plan. That is, MySQL explains how it would process the
+            <literal>SELECT</literal>, including information about how
+            tables are joined and in which order.
           </para>
         </listitem>
 
@@ -724,39 +725,42 @@
       <remark role="help-description-end"/>
 
       <para>
-        This section provides information about the second use of
-        <literal>EXPLAIN</literal>.
+        This section describes the second use of
+        <literal>EXPLAIN</literal> for obtaining query execution plan
+        information. For a description of the
+        <literal>DESCRIBE</literal> and <literal>SHOW COLUMNS</literal>
+        statements, see <xref linkend="describe"/>, and
+        <xref linkend="show-columns"/>.
       </para>
 
       <para>
         With the help of <literal>EXPLAIN</literal>, you can see where
         you should add indexes to tables in order to get a faster
-        <literal>SELECT</literal> that uses indexes to find records.
+        <literal>SELECT</literal> that uses indexes to find rows. You
+        can also use <literal>EXPLAIN</literal> to see whether the
+        optimizer joins the tables in an optimal order. To force the
+        optimizer to use a join order corresponding to the order in
+        which the tables are named in the <literal>SELECT</literal>
+        statement, begin the statement with <literal>SELECT
+        STRAIGHT_JOIN</literal> rather than just
+        <literal>SELECT</literal>.
       </para>
 
       <para>
-        If you have a problem with incorrect index usage, you should run
-        <literal>ANALYZE TABLE</literal> to update table statistics such
-        as cardinality of keys, which can affect the choices the
-        optimizer makes. See <xref linkend="analyze-table"/>.
+        If you have a problem with indexes not being used when you
+        believe that they should be, you should run <literal>ANALYZE
+        TABLE</literal> to update table statistics such as cardinality
+        of keys, that can affect the choices the optimizer makes. See
+        <xref linkend="analyze-table"/>.
       </para>
 
       <para>
-        You can also see whether the optimizer joins the tables in an
-        optimal order. To force the optimizer to use a join order
-        corresponding to the order in which the tables are named in the
-        <literal>SELECT</literal> statement, begin the statement with
-        <literal>SELECT STRAIGHT_JOIN</literal> rather than just
-        <literal>SELECT</literal>.
-      </para>
-
-      <para>
         <literal>EXPLAIN</literal> returns a row of information for each
         table used in the <literal>SELECT</literal> statement. The
         tables are listed in the output in the order that MySQL would
         read them while processing the query. MySQL resolves all joins
         using a <firstterm>single-sweep multi-join</firstterm> method.
-        This means that MySQL reads a row from the first table, then
+        This means that MySQL reads a row from the first table, and then
         finds a matching row in the second table, the third table, and
         so on. When all tables are processed, MySQL outputs the selected
         columns and backtracks through the table list until a table is
@@ -1289,7 +1293,7 @@
             of the key that MySQL decided to use. The length is
             <literal>NULL</literal> if the <literal>key</literal> column
             says <literal>NULL</literal>. Note that the value of
-            <literal>key_len</literal> allows you to determine how many
+            <literal>key_len</literal> enables you to determine how many
             parts of a multiple-part key MySQL actually uses.
           </para>
         </listitem>
@@ -1390,7 +1394,7 @@
             <listitem>
               <para>
                 <literal>range checked for each record (index map:
-                #)</literal>
+                <replaceable>N</replaceable>)</literal>
               </para>
 
               <para>
@@ -1843,9 +1847,9 @@
       </para>
 
       <para>
-        For writes, however, you need four seek requests (as above) to
-        find where to place the new index and normally two seeks to
-        update the index and write the row.
+        For writes, however, you need four seek requests to find where
+        to place the new index and normally two seeks to update the
+        index and write the row.
       </para>
 
       <para>
@@ -1918,9 +1922,9 @@
             <command>myisamchk --sort-index --sort-records=1</command>
             (if you want to sort on index 1). This is a good way to make
             queries faster if you have a unique index from which you
-            want to read all records in order according to the index.
-            Note that the first time you sort a large table this way, it
-            may take a long time.
+            want to read all rows in order according to the index. Note
+            that the first time you sort a large table this way, it may
+            take a long time.
           </para>
         </listitem>
 
@@ -2007,9 +2011,9 @@
             <literal>COUNT(*)</literal> on a single table without a
             <literal>WHERE</literal> is retrieved directly from the
             table information for <literal>MyISAM</literal> and
-            <literal>HEAP</literal> tables. This is also done for any
-            <literal>NOT NULL</literal> expression when used with only
-            one table.
+            <literal>MEMORY</literal> (<literal>HASH</literal>) tables.
+            This is also done for any <literal>NOT NULL</literal>
+            expression when used with only one table.
           </para>
         </listitem>
 
@@ -2034,7 +2038,7 @@
           <para>
             For each table in a join, a simpler <literal>WHERE</literal>
             is constructed to get a fast <literal>WHERE</literal>
-            evaluation for the table and also to skip records as soon as
+            evaluation for the table and also to skip rows as soon as
             possible.
           </para>
         </listitem>
@@ -2136,7 +2140,7 @@
 
         <listitem>
           <para>
-            Before each record is output, those that do not match the
+            Before each row is output, those that do not match the
             <literal>HAVING</literal> clause are skipped.
           </para>
         </listitem>
@@ -2197,8 +2201,8 @@
 
       <para>
         The <literal>range</literal> access method uses a single index
-        to retrieve a subset of table records that are contained within
-        one or several index value intervals. It can be used for a
+        to retrieve a subset of table rows that are contained within one
+        or several index value intervals. It can be used for a
         single-part or multiple-part index. A detailed description of
         how intervals are extracted from the <literal>WHERE</literal>
         clause is given in the following sections.
@@ -2364,7 +2368,7 @@
               LIKE '%b'</literal> because they cannot be used for a
               range scan. The right way to remove them is to replace
               them with <literal>TRUE</literal>, so that we do not miss
-              any matching records when doing the range scan. Having
+              any matching rows when doing the range scan. Having
               replaced them with <literal>TRUE</literal>, we get:
             </para>
 
@@ -2453,8 +2457,8 @@
         <para>
           Range conditions on a multiple-part index are an extension of
           range conditions for a single-part index. A range condition on
-          a multiple-part index restricts index records to lie within
-          one or several key tuple intervals. Key tuple intervals are
+          a multiple-part index restricts index rows to lie within one
+          or several key tuple intervals. Key tuple intervals are
           defined over a set of key tuples, using ordering from the
           index.
         </para>
@@ -2562,7 +2566,7 @@
               <literal>'<replaceable>pattern</replaceable>'</literal>
               does not start with a wildcard). An interval can be used
               as long as it is possible to determine a single key tuple
-              containing all records that match the condition (or two
+              containing all rows that match the condition (or two
               intervals if <literal>&lt;&gt;</literal> or
               <literal>!=</literal> is used). For example, for this
               condition:
@@ -2584,7 +2588,7 @@
 
             <para>
               It is possible that the created interval contains more
-              records than the initial condition. For example, the
+              rows than the initial condition. For example, the
               preceding interval includes the value <literal>('foo', 11,
               0)</literal>, which does not satisfy the original
               condition.
@@ -2593,13 +2597,13 @@
 
           <listitem>
             <para>
-              If conditions that cover sets of records contained within
+              If conditions that cover sets of rows contained within
               intervals are combined with <literal>OR</literal>, they
-              form a condition that covers a set of records contained
+              form a condition that covers a set of rows contained
               within the union of their intervals. If the conditions are
               combined with <literal>AND</literal>, they form a
-              condition that covers a set of records contained within
-              the intersection of their intervals. For example, for this
+              condition that covers a set of rows contained within the
+              intersection of their intervals. For example, for this
               condition on a two-part index:
             </para>
 
@@ -3121,7 +3125,7 @@
           <para>
             The type of table index used does not store rows in order.
             For example, this is true for a <literal>HASH</literal>
-            index in a <literal>HEAP</literal> table.
+            index in a <literal>MEMORY</literal> table.
           </para>
         </listitem>
 
@@ -3433,10 +3437,11 @@
         </para>
 
         <para>
-          The following queries do not work with the first method above,
-          but still work with the second index access method (assuming
-          we have the aforementioned index <literal>idx</literal> on
-          table <literal>t1</literal>):
+          The following queries do not work with the loose index scan
+          access method described earlier, but still work with the tight
+          index scan access method (assuming that there is an index
+          <literal>idx(c1,c2,c3)</literal> on table
+          <literal>t1(c1,c2,c3,c4)</literal>).
         </para>
 
         <itemizedlist>
@@ -3692,7 +3697,7 @@
       </indexterm>
 
       <para>
-        The time required for inserting a record is determined by the
+        The time required for inserting a row is determined by the
         following factors, where the numbers indicate approximate
         proportions:
       </para>
@@ -3719,7 +3724,7 @@
 
         <listitem>
           <para>
-            Inserting record: (1 x size of record)
+            Inserting row: (1 x size of row)
           </para>
         </listitem>
 
@@ -3990,10 +3995,10 @@
 
       <para>
         Note that for a <literal>MyISAM</literal> table that uses
-        dynamic record format, updating a record to a longer total
-        length may split the record. If you do this often, it is very
-        important to use <literal>OPTIMIZE TABLE</literal> occasionally.
-        See <xref linkend="optimize-table"/>.
+        dynamic row format, updating a row to a longer total length may
+        split the row. If you do this often, it is very important to use
+        <literal>OPTIMIZE TABLE</literal> occasionally. See
+        <xref linkend="optimize-table"/>.
       </para>
 
     </section>
@@ -4003,8 +4008,8 @@
       <title>&title-delete-speed;</title>
 
       <para>
-        The time required to delete individual records is exactly
-        proportional to the number of indexes. To delete records more
+        The time required to delete individual rows is exactly
+        proportional to the number of indexes. To delete rows more
         quickly, you can increase the size of the key cache. See
         <xref linkend="server-parameters"/>.
       </para>
@@ -4131,9 +4136,9 @@
             For <literal>MyISAM</literal> tables that change frequently,
             you should try to avoid all variable-length columns
             (<literal>VARCHAR</literal>, <literal>BLOB</literal>, and
-            <literal>TEXT</literal>). The table uses dynamic record
-            format if it includes even a single variable-length column.
-            See <xref linkend="storage-engines"/>.
+            <literal>TEXT</literal>). The table uses dynamic row format
+            if it includes even a single variable-length column. See
+            <xref linkend="storage-engines"/>.
           </para>
         </listitem>
 
@@ -4146,10 +4151,10 @@
             modern disks can read the entire row fast enough for most
             applications. The only cases where splitting up a table
             makes an appreciable difference is if it is a
-            <literal>MyISAM</literal> table using dynamic record format
-            (see above) that you can change to a fixed record size, or
-            if you very often need to scan the table but do not need
-            most of the columns. See <xref linkend="storage-engines"/>.
+            <literal>MyISAM</literal> table using dynamic row format
+            that you can change to a fixed row size, or if you very
+            often need to scan the table but do not need most of the
+            columns. See <xref linkend="storage-engines"/>.
           </para>
         </listitem>
 
@@ -4254,8 +4259,7 @@
           <para>
             Use <literal>INSERT DELAYED</literal> when you do not need
             to know when your data is written. This speeds things up
-            because many records can be written with a single disk
-            write.
+            because many rows can be written with a single disk write.
           </para>
         </listitem>
 
@@ -4593,9 +4597,9 @@
         is, you can insert rows into a <literal>MyISAM</literal> table
         at the same time other clients are reading from it. No conflict
         occurs if the data file contains no free blocks in the middle,
-        because in that case, records always are inserted at the end of
-        the data file. (Holes can result from rows having been deleted
-        from or updated in the middle of the table.) If there are holes,
+        because in that case, rows always are inserted at the end of the
+        data file. (Holes can result from rows having been deleted from
+        or updated in the middle of the table.) If there are holes,
         concurrent inserts are re-enabled automatically when all holes
         have been filled with new data.
       </para>
@@ -4604,9 +4608,8 @@
         If you want to perform many <literal>INSERT</literal> and
         <literal>SELECT</literal> operations on a table when concurrent
         inserts are not possible, you can insert rows in a temporary
-        table and update the real table with the records from the
-        temporary table once in a while. This can be done with the
-        following code:
+        table and update the real table with the rows from the temporary
+        table once in a while. This can be done with the following code:
       </para>
 
 <programlisting>
@@ -5193,7 +5196,7 @@
             For <literal>MyISAM</literal> tables, if you do not have any
             variable-length columns (<literal>VARCHAR</literal>,
             <literal>TEXT</literal>, or <literal>BLOB</literal>
-            columns), a fixed-size record format is used. This is faster
+            columns), a fixed-size row format is used. This is faster
             but unfortunately may waste some space. See
             <xref linkend="myisam-table-formats"/>. You can hint that
             you want to have fixed length rows even if you have
@@ -5470,13 +5473,13 @@
 
       <para>
         Indexes are used to find rows with specific column values
-        quickly. Without an index, MySQL must begin with the first
-        record and then read through the entire table to find the
-        relevant rows. The larger the table, the more this costs. If the
-        table has an index for the columns in question, MySQL can
-        quickly determine the position to seek to in the middle of the
-        data file without having to look at all the data. If a table has
-        1,000 rows, this is at least 100 times faster than reading
+        quickly. Without an index, MySQL must begin with the first row
+        and then read through the entire table to find the relevant
+        rows. The larger the table, the more this costs. If the table
+        has an index for the columns in question, MySQL can quickly
+        determine the position to seek to in the middle of the data file
+        without having to look at all the data. If a table has 1,000
+        rows, this is at least 100 times faster than reading
         sequentially. Note that if you need to access most of the rows,
         it is faster to read sequentially, because this minimizes disk
         seeks.
@@ -6021,7 +6024,7 @@
         </itemizedlist>
 
         <para>
-          Shared access to the key cache allows the server to improve
+          Shared access to the key cache enables the server to improve
           throughput significantly.
         </para>
 
@@ -6036,9 +6039,8 @@
           not eliminate contention among threads entirely. They still
           compete for control structures that manage access to the key
           cache buffers. To reduce key cache access contention further,
-          MySQL 4.1.1 offers the feature of multiple key caches. This
-          allows you to assign different table indexes to different key
-          caches.
+          MySQL 4.1.1 also provides multiple key caches, which enables
+          you to assign different table indexes to different key caches.
         </para>
 
         <para>
@@ -6477,9 +6479,9 @@
       <para>
         Storage engines collect statistics about tables for use by the
         optimizer. Table statistics are based on value groups, where a
-        value group is a set of records with the same key prefix value.
-        For optimizer purposes, an important statistic is the average
-        value group size.
+        value group is a set of rows with the same key prefix value. For
+        optimizer purposes, an important statistic is the average value
+        group size.
       </para>
 
       <para>
@@ -6524,10 +6526,10 @@
         which is the number of value groups. The <literal>SHOW
         INDEX</literal> statement displays a cardinality value based on
         <replaceable>N</replaceable>/<replaceable>S</replaceable>, where
-        <replaceable>N</replaceable> is the number of records in the
-        table and <replaceable>S</replaceable> is the average value
-        group size. That ratio yields an approximate number of value
-        groups in the table.
+        <replaceable>N</replaceable> is the number of rows in the table
+        and <replaceable>S</replaceable> is the average value group
+        size. That ratio yields an approximate number of value groups in
+        the table.
       </para>
 
       <para>
@@ -7699,9 +7701,9 @@
           <para>
             All joins are executed in a single pass, and most joins can
             be done without even using a temporary table. Most temporary
-            tables are memory-based (<literal>HEAP</literal>) tables.
-            Temporary tables with a large record length (calculated as
-            the sum of all column lengths) or that contain
+            tables are memory-based (<literal>MEMORY</literal>) tables.
+            Temporary tables with a large row length (calculated as the
+            sum of all column lengths) or that contain
             <literal>BLOB</literal> columns are stored on disk.
           </para>
 

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-5.0/database-administration.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -22298,21 +22298,13 @@
       </para>
 
       <para>
-        To change the error message file, you should edit the
-        <filename>errmsg.txt</filename> file, and then execute the
-        following command to generate the
-        <filename>errmsg.sys</filename> file:
+        You can also change the error messages produced by the server.
+        Details can be found in the MySQL Internals manual, available at
+        <ulink url="&base-url-docs;"/>. If you upgrade to a newer
+        version of MySQL after changing the error messages, remember to
+        repeat your changes after the upgrade.
       </para>
 
-<programlisting>
-shell&gt; <userinput>comp_err errmsg.txt errmsg.sys</userinput>
-</programlisting>
-
-      <para>
-        If you upgrade to a newer version of MySQL, remember to repeat
-        your changes with the new <filename>errmsg.txt</filename> file.
-      </para>
-
     </section>
 
     <section id="adding-character-set">

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-5.0/optimization.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -235,7 +235,7 @@
       <para>
         If you strive for database independence, you need to get a good
         feeling for each SQL server's bottlenecks. For example, MySQL is
-        very fast in retrieving and updating records for
+        very fast in retrieving and updating rows for
         <literal>MyISAM</literal> tables, but has a problem in mixing
         slow readers and writers on the same table. Oracle, on the other
         hand, has a big problem when you try to access rows that you
@@ -258,7 +258,7 @@
         system (such as the <literal>REPLACE</literal> statement, which
         is specific to MySQL), you should implement the same feature for
         other SQL servers by coding an alternative method. Although the
-        alternative might be slower, it allows the other servers to
+        alternative might be slower, it enables the other servers to
         perform the same tasks.
       </para>
 
@@ -534,13 +534,12 @@
 
       <para>
         You should definitely benchmark your application and database to
-        find out where the bottlenecks are. By fixing a bottleneck (or
-        by replacing it with a <quote>dummy</quote> module), you can
-        then proceed to identify the next bottleneck. Even if the
-        overall performance for your application currently is
-        acceptable, you should at least make a plan for each bottleneck
-        and decide how to solve it if someday you really need the extra
-        performance.
+        find out where the bottlenecks are. After fixing one bottleneck
+        (or by replacing it with a <quote>dummy</quote> module), you can
+        proceed to identify the next bottleneck. Even if the overall
+        performance for your application currently is acceptable, you
+        should at least make a plan for each bottleneck and decide how
+        to solve it if someday you really need the extra performance.
       </para>
 
       <para>
@@ -575,8 +574,8 @@
         benchmarking your whole application under the worst possible
         load. You can use Super Smack, available at
         <ulink url="http://jeremy.zawodny.com/mysql/super-smack/"/>. As
-        suggested by its name, it can bring a system to its knees if you
-        ask it, so make sure to use it only on your development systems.
+        suggested by its name, it can bring a system to its knees, so
+        make sure to use it only on your development systems.
       </para>
 
     </section>
@@ -713,9 +712,11 @@
         <listitem>
           <para>
             When you precede a <literal>SELECT</literal> statement with
-            the keyword <literal>EXPLAIN</literal>, MySQL explains how
-            it would process the <literal>SELECT</literal>, providing
-            information about how tables are joined and in which order.
+            the keyword <literal>EXPLAIN</literal>, MySQL displays
+            information from the optimizer about the query execution
+            plan. That is, MySQL explains how it would process the
+            <literal>SELECT</literal>, including information about how
+            tables are joined and in which order.
           </para>
         </listitem>
 
@@ -724,39 +725,42 @@
       <remark role="help-description-end"/>
 
       <para>
-        This section provides information about the second use of
-        <literal>EXPLAIN</literal>.
+        This section describes the second use of
+        <literal>EXPLAIN</literal> for obtaining query execution plan
+        information. For a description of the
+        <literal>DESCRIBE</literal> and <literal>SHOW COLUMNS</literal>
+        statements, see <xref linkend="describe"/>, and
+        <xref linkend="show-columns"/>.
       </para>
 
       <para>
         With the help of <literal>EXPLAIN</literal>, you can see where
         you should add indexes to tables in order to get a faster
-        <literal>SELECT</literal> that uses indexes to find records.
+        <literal>SELECT</literal> that uses indexes to find rows. You
+        can also use <literal>EXPLAIN</literal> to see whether the
+        optimizer joins the tables in an optimal order. To force the
+        optimizer to use a join order corresponding to the order in
+        which the tables are named in the <literal>SELECT</literal>
+        statement, begin the statement with <literal>SELECT
+        STRAIGHT_JOIN</literal> rather than just
+        <literal>SELECT</literal>.
       </para>
 
       <para>
-        If you have a problem with incorrect index usage, you should run
-        <literal>ANALYZE TABLE</literal> to update table statistics such
-        as cardinality of keys, which can affect the choices the
-        optimizer makes. See <xref linkend="analyze-table"/>.
+        If you have a problem with indexes not being used when you
+        believe that they should be, you should run <literal>ANALYZE
+        TABLE</literal> to update table statistics such as cardinality
+        of keys, that can affect the choices the optimizer makes. See
+        <xref linkend="analyze-table"/>.
       </para>
 
       <para>
-        You can also see whether the optimizer joins the tables in an
-        optimal order. To force the optimizer to use a join order
-        corresponding to the order in which the tables are named in the
-        <literal>SELECT</literal> statement, begin the statement with
-        <literal>SELECT STRAIGHT_JOIN</literal> rather than just
-        <literal>SELECT</literal>.
-      </para>
-
-      <para>
         <literal>EXPLAIN</literal> returns a row of information for each
         table used in the <literal>SELECT</literal> statement. The
         tables are listed in the output in the order that MySQL would
         read them while processing the query. MySQL resolves all joins
         using a <firstterm>single-sweep multi-join</firstterm> method.
-        This means that MySQL reads a row from the first table, then
+        This means that MySQL reads a row from the first table, and then
         finds a matching row in the second table, the third table, and
         so on. When all tables are processed, MySQL outputs the selected
         columns and backtracks through the table list until a table is
@@ -1298,7 +1302,7 @@
             of the key that MySQL decided to use. The length is
             <literal>NULL</literal> if the <literal>key</literal> column
             says <literal>NULL</literal>. Note that the value of
-            <literal>key_len</literal> allows you to determine how many
+            <literal>key_len</literal> enables you to determine how many
             parts of a multiple-part key MySQL actually uses.
           </para>
         </listitem>
@@ -1399,7 +1403,7 @@
             <listitem>
               <para>
                 <literal>range checked for each record (index map:
-                #)</literal>
+                <replaceable>N</replaceable>)</literal>
               </para>
 
               <para>
@@ -1543,9 +1547,9 @@
                 cases, the condition is <quote>pushed down</quote> to
                 the cluster's data nodes where it is evaluated in all
                 partitions simultaneously. This eliminates the need to
-                send non-matching records over the network, and can
-                speed up such queries by a factor of 5 to 10 times over
-                cases where condition pushdown could be but is not used.
+                send non-matching rows over the network, and can speed
+                up such queries by a factor of 5 to 10 times over cases
+                where condition pushdown could be but is not used.
               </para>
 
               <para>
@@ -2009,9 +2013,9 @@
       </para>
 
       <para>
-        For writes, however, you need four seek requests (as above) to
-        find where to place the new index and normally two seeks to
-        update the index and write the row.
+        For writes, however, you need four seek requests to find where
+        to place the new index and normally two seeks to update the
+        index and write the row.
       </para>
 
       <para>
@@ -2085,9 +2089,9 @@
             <command>myisamchk --sort-index --sort-records=1</command>
             (if you want to sort on index 1). This is a good way to make
             queries faster if you have a unique index from which you
-            want to read all records in order according to the index.
-            Note that the first time you sort a large table this way, it
-            may take a long time.
+            want to read all rows in order according to the index. Note
+            that the first time you sort a large table this way, it may
+            take a long time.
           </para>
         </listitem>
 
@@ -2174,7 +2178,7 @@
             <literal>COUNT(*)</literal> on a single table without a
             <literal>WHERE</literal> is retrieved directly from the
             table information for <literal>MyISAM</literal> and
-            <literal>HEAP</literal> tables. This is also done for any
+            <literal>MEMORY</literal> tables. This is also done for any
             <literal>NOT NULL</literal> expression when used with only
             one table.
           </para>
@@ -2201,7 +2205,7 @@
           <para>
             For each table in a join, a simpler <literal>WHERE</literal>
             is constructed to get a fast <literal>WHERE</literal>
-            evaluation for the table and also to skip records as soon as
+            evaluation for the table and also to skip rows as soon as
             possible.
           </para>
         </listitem>
@@ -2303,7 +2307,7 @@
 
         <listitem>
           <para>
-            Before each record is output, those that do not match the
+            Before each row is output, those that do not match the
             <literal>HAVING</literal> clause are skipped.
           </para>
         </listitem>
@@ -2364,8 +2368,8 @@
 
       <para>
         The <literal>range</literal> access method uses a single index
-        to retrieve a subset of table records that are contained within
-        one or several index value intervals. It can be used for a
+        to retrieve a subset of table rows that are contained within one
+        or several index value intervals. It can be used for a
         single-part or multiple-part index. A detailed description of
         how intervals are extracted from the <literal>WHERE</literal>
         clause is given in the following sections.
@@ -2531,7 +2535,7 @@
               LIKE '%b'</literal> because they cannot be used for a
               range scan. The right way to remove them is to replace
               them with <literal>TRUE</literal>, so that we do not miss
-              any matching records when doing the range scan. Having
+              any matching rows when doing the range scan. Having
               replaced them with <literal>TRUE</literal>, we get:
             </para>
 
@@ -2620,8 +2624,8 @@
         <para>
           Range conditions on a multiple-part index are an extension of
           range conditions for a single-part index. A range condition on
-          a multiple-part index restricts index records to lie within
-          one or several key tuple intervals. Key tuple intervals are
+          a multiple-part index restricts index rows to lie within one
+          or several key tuple intervals. Key tuple intervals are
           defined over a set of key tuples, using ordering from the
           index.
         </para>
@@ -2729,7 +2733,7 @@
               <literal>'<replaceable>pattern</replaceable>'</literal>
               does not start with a wildcard). An interval can be used
               as long as it is possible to determine a single key tuple
-              containing all records that match the condition (or two
+              containing all rows that match the condition (or two
               intervals if <literal>&lt;&gt;</literal> or
               <literal>!=</literal> is used). For example, for this
               condition:
@@ -2751,7 +2755,7 @@
 
             <para>
               It is possible that the created interval contains more
-              records than the initial condition. For example, the
+              rows than the initial condition. For example, the
               preceding interval includes the value <literal>('foo', 11,
               0)</literal>, which does not satisfy the original
               condition.
@@ -2760,13 +2764,13 @@
 
           <listitem>
             <para>
-              If conditions that cover sets of records contained within
+              If conditions that cover sets of rows contained within
               intervals are combined with <literal>OR</literal>, they
-              form a condition that covers a set of records contained
+              form a condition that covers a set of rows contained
               within the union of their intervals. If the conditions are
               combined with <literal>AND</literal>, they form a
-              condition that covers a set of records contained within
-              the intersection of their intervals. For example, for this
+              condition that covers a set of rows contained within the
+              intersection of their intervals. For example, for this
               condition on a two-part index:
             </para>
 
@@ -3080,7 +3084,7 @@
 
         <para>
           If all columns used in the query are covered by the used
-          indexes, full table records are not retrieved and
+          indexes, full table rows are not retrieved and
           (<literal>EXPLAIN</literal> output contains <literal>Using
           index</literal> in <literal>Extra</literal> field in this
           case). Here is an example of such query:
@@ -3092,15 +3096,15 @@
 
         <para>
           If the used indexes don't cover all columns used in the query,
-          full records are retrieved only when the range conditions for
-          all used keys are satisfied.
+          full rows are retrieved only when the range conditions for all
+          used keys are satisfied.
         </para>
 
         <para>
           If one of the merged conditions is a condition over a primary
           key of an <literal>InnoDB</literal> or <literal>BDB</literal>
-          table, it is not used for record retrieval, but is used to
-          filter out records retrieved using other conditions.
+          table, it is not used for row retrieval, but is used to filter
+          out rows retrieved using other conditions.
         </para>
 
       </section>
@@ -3187,8 +3191,7 @@
         <para>
           The difference between the sort-union algorithm and the union
           algorithm is that the sort-union algorithm must first fetch
-          row IDs for all records and sort them before returning any
-          records.
+          row IDs for all rows and sort them before returning any rows.
         </para>
 
       </section>
@@ -3831,7 +3834,7 @@
       </para>
 
       <para>
-        Suppose we have a join query over 3 tables
+        Suppose that we have a join query over 3 tables
         <literal>T1,T2,T3</literal> of the form:
       </para>
 
@@ -4035,7 +4038,7 @@
         When discussing about nested-loop algorithm for inner joins, we
         omitted some details whose impact on the performance of query
         execution may be huge. We did not mention so-called
-        <quote>pushed-down</quote> conditions. Suppose our
+        <quote>pushed-down</quote> conditions. Suppose that our
         <literal>WHERE</literal> condition
         <literal>P(T1,T2,T3)</literal> can be represented by a
         conjunctive formula:
@@ -4178,12 +4181,12 @@
         join operation, it takes into consideration only the plans
         where, for each such operation, the outer tables are accessed
         before the inner tables. The optimizer options are limited
-        because only such plans allow us to execute queries with outer
+        because only such plans enables us to execute queries with outer
         joins operations by the nested loop schema.
       </para>
 
       <para>
-        Suppose we have a query of the form:
+        Suppose that we have a query of the form:
       </para>
 
 <programlisting>
@@ -4542,7 +4545,7 @@
           <para>
             The type of table index used does not store rows in order.
             For example, this is true for a <literal>HASH</literal>
-            index in a <literal>HEAP</literal> table.
+            index in a <literal>MEMORY</literal> table.
           </para>
         </listitem>
 
@@ -4736,7 +4739,7 @@
           The most efficient way is when the index is used to directly
           retrieve the group fields. With this access method, MySQL uses
           the property of some index types (for example, B-Trees) that
-          the keys are ordered. This property allows use of lookup
+          the keys are ordered. This property enables use of lookup
           groups in an index without having to consider all keys in the
           index that satisfy all <literal>WHERE</literal> conditions.
           This access method considers only a fraction of the keys in an
@@ -4799,8 +4802,9 @@
 
         <para>
           The following queries provide several examples that fall into
-          this category, assuming there is an index <literal>idx(c1, c2,
-          c3)</literal> on table <literal>t1(c1,c2,c3,c4)</literal>:
+          this category, assuming that there is an index
+          <literal>idx(c1,c2,c3)</literal> on table
+          <literal>t1(c1,c2,c3,c4)</literal>:
         </para>
 
 <programlisting>
@@ -4899,10 +4903,11 @@
         </para>
 
         <para>
-          The following queries do not work with the first method above,
-          but still work with the second index access method (assuming
-          we have the aforementioned index <literal>idx</literal> on
-          table <literal>t1</literal>):
+          The following queries do not work with the loose index scan
+          access method described earlier, but still work with the tight
+          index scan access method (assuming that there is an index
+          <literal>idx(c1,c2,c3)</literal> on table
+          <literal>t1(c1,c2,c3,c4)</literal>).
         </para>
 
         <itemizedlist>
@@ -5158,7 +5163,7 @@
       </indexterm>
 
       <para>
-        The time required for inserting a record is determined by the
+        The time required for inserting a row is determined by the
         following factors, where the numbers indicate approximate
         proportions:
       </para>
@@ -5185,7 +5190,7 @@
 
         <listitem>
           <para>
-            Inserting record: (1 x size of record)
+            Inserting row: (1 x size of row)
           </para>
         </listitem>
 
@@ -5456,10 +5461,10 @@
 
       <para>
         Note that for a <literal>MyISAM</literal> table that uses
-        dynamic record format, updating a record to a longer total
-        length may split the record. If you do this often, it is very
-        important to use <literal>OPTIMIZE TABLE</literal> occasionally.
-        See <xref linkend="optimize-table"/>.
+        dynamic row format, updating a row to a longer total length may
+        split the row. If you do this often, it is very important to use
+        <literal>OPTIMIZE TABLE</literal> occasionally. See
+        <xref linkend="optimize-table"/>.
       </para>
 
     </section>
@@ -5469,8 +5474,8 @@
       <title>&title-delete-speed;</title>
 
       <para>
-        The time required to delete individual records is exactly
-        proportional to the number of indexes. To delete records more
+        The time required to delete individual rows is exactly
+        proportional to the number of indexes. To delete rows more
         quickly, you can increase the size of the key cache. See
         <xref linkend="server-parameters"/>.
       </para>
@@ -5597,9 +5602,9 @@
             For <literal>MyISAM</literal> tables that change frequently,
             you should try to avoid all variable-length columns
             (<literal>VARCHAR</literal>, <literal>BLOB</literal>, and
-            <literal>TEXT</literal>). The table uses dynamic record
-            format if it includes even a single variable-length column.
-            See <xref linkend="storage-engines"/>.
+            <literal>TEXT</literal>). The table uses dynamic row format
+            if it includes even a single variable-length column. See
+            <xref linkend="storage-engines"/>.
           </para>
         </listitem>
 
@@ -5612,10 +5617,10 @@
             modern disks can read the entire row fast enough for most
             applications. The only cases where splitting up a table
             makes an appreciable difference is if it is a
-            <literal>MyISAM</literal> table using dynamic record format
-            (see above) that you can change to a fixed record size, or
-            if you very often need to scan the table but do not need
-            most of the columns. See <xref linkend="storage-engines"/>.
+            <literal>MyISAM</literal> table using dynamic row format
+            that you can change to a fixed row size, or if you very
+            often need to scan the table but do not need most of the
+            columns. See <xref linkend="storage-engines"/>.
           </para>
         </listitem>
 
@@ -5719,8 +5724,7 @@
           <para>
             Use <literal>INSERT DELAYED</literal> when you do not need
             to know when your data is written. This speeds things up
-            because many records can be written with a single disk
-            write.
+            because many rows can be written with a single disk write.
           </para>
         </listitem>
 
@@ -6054,9 +6058,9 @@
         is, you can insert rows into a <literal>MyISAM</literal> table
         at the same time other clients are reading from it. No conflict
         occurs if the data file contains no free blocks in the middle,
-        because in that case, records always are inserted at the end of
-        the data file. (Holes can result from rows having been deleted
-        from or updated in the middle of the table.) If there are holes,
+        because in that case, rows always are inserted at the end of the
+        data file. (Holes can result from rows having been deleted from
+        or updated in the middle of the table.) If there are holes,
         concurrent inserts are re-enabled automatically when all holes
         have been filled with new data.
       </para>
@@ -6065,9 +6069,8 @@
         If you want to perform many <literal>INSERT</literal> and
         <literal>SELECT</literal> operations on a table when concurrent
         inserts are not possible, you can insert rows in a temporary
-        table and update the real table with the records from the
-        temporary table once in a while. This can be done with the
-        following code:
+        table and update the real table with the rows from the temporary
+        table once in a while. This can be done with the following code:
       </para>
 
 <programlisting>
@@ -6653,7 +6656,7 @@
             For <literal>MyISAM</literal> tables, if you do not have any
             variable-length columns (<literal>VARCHAR</literal>,
             <literal>TEXT</literal>, or <literal>BLOB</literal>
-            columns), a fixed-size record format is used. This is faster
+            columns), a fixed-size row format is used. This is faster
             but unfortunately may waste some space. See
             <xref linkend="myisam-table-formats"/>. You can hint that
             you want to have fixed length rows even if you have
@@ -6667,7 +6670,7 @@
           <para>
             Starting with MySQL/InnoDB 5.0.3, <literal>InnoDB</literal>
             tables use a more compact storage format. In earlier
-            versions of MySQL, <literal>InnoDB</literal> records contain
+            versions of MySQL, <literal>InnoDB</literal> rows contain
             some redundant information, such as the number of columns
             and the length of each column, even for fixed-size columns.
             By default, tables are created in the compact format
@@ -6847,9 +6850,8 @@
       </para>
 
       <para>
-        The <literal>MEMORY</literal> (<literal>HEAP</literal>) storage
-        engine uses hash indexes by default, but also supports B-tree
-        indexes.
+        The <literal>MEMORY</literal> storage engine uses hash indexes
+        by default, but also supports B-tree indexes.
       </para>
 
     </section>
@@ -6961,13 +6963,13 @@
 
       <para>
         Indexes are used to find rows with specific column values
-        quickly. Without an index, MySQL must begin with the first
-        record and then read through the entire table to find the
-        relevant rows. The larger the table, the more this costs. If the
-        table has an index for the columns in question, MySQL can
-        quickly determine the position to seek to in the middle of the
-        data file without having to look at all the data. If a table has
-        1,000 rows, this is at least 100 times faster than reading
+        quickly. Without an index, MySQL must begin with the first row
+        and then read through the entire table to find the relevant
+        rows. The larger the table, the more this costs. If the table
+        has an index for the columns in question, MySQL can quickly
+        determine the position to seek to in the middle of the data file
+        without having to look at all the data. If a table has 1,000
+        rows, this is at least 100 times faster than reading
         sequentially. Note that if you need to access most of the rows,
         it is faster to read sequentially, because this minimizes disk
         seeks.
@@ -7490,7 +7492,7 @@
         </itemizedlist>
 
         <para>
-          Shared access to the key cache allows the server to improve
+          Shared access to the key cache enables the server to improve
           throughput significantly.
         </para>
 
@@ -7506,8 +7508,8 @@
           compete for control structures that manage access to the key
           cache buffers. To reduce key cache access contention further,
           MySQL &current-series; also provides multiple key caches,
-          which allow you to assign different table indexes to different
-          key caches.
+          which enables you to assign different table indexes to
+          different key caches.
         </para>
 
         <para>
@@ -7942,9 +7944,9 @@
       <para>
         Storage engines collect statistics about tables for use by the
         optimizer. Table statistics are based on value groups, where a
-        value group is a set of records with the same key prefix value.
-        For optimizer purposes, an important statistic is the average
-        value group size.
+        value group is a set of rows with the same key prefix value. For
+        optimizer purposes, an important statistic is the average value
+        group size.
       </para>
 
       <para>
@@ -7989,10 +7991,10 @@
         which is the number of value groups. The <literal>SHOW
         INDEX</literal> statement displays a cardinality value based on
         <replaceable>N</replaceable>/<replaceable>S</replaceable>, where
-        <replaceable>N</replaceable> is the number of records in the
-        table and <replaceable>S</replaceable> is the average value
-        group size. That ratio yields an approximate number of value
-        groups in the table.
+        <replaceable>N</replaceable> is the number of rows in the table
+        and <replaceable>S</replaceable> is the average value group
+        size. That ratio yields an approximate number of value groups in
+        the table.
       </para>
 
       <para>
@@ -9287,9 +9289,9 @@
           <para>
             All joins are executed in a single pass, and most joins can
             be done without even using a temporary table. Most temporary
-            tables are memory-based (<literal>HEAP</literal>) tables.
-            Temporary tables with a large record length (calculated as
-            the sum of all column lengths) or that contain
+            tables are memory-based (<literal>MEMORY</literal>) tables.
+            Temporary tables with a large row length (calculated as the
+            sum of all column lengths) or that contain
             <literal>BLOB</literal> columns are stored on disk.
           </para>
 

Modified: trunk/refman-5.1/client-utility-programs.xml
===================================================================
--- trunk/refman-5.1/client-utility-programs.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-5.1/client-utility-programs.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -7910,6 +7910,7 @@
           <command>mysqlslap</command> is designed to emulate client
           load for a MySQL server and report the timing of each stage.
           It works as if multiple clients are accessing the server.
+          <command>mysqlslap</command> is available as of MySQL 5.1.4.
         </para>
 
         <remark role="todo">

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-5.1/database-administration.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -22239,21 +22239,13 @@
       </para>
 
       <para>
-        To change the error message file, you should edit the
-        <filename>errmsg.txt</filename> file, and then execute the
-        following command to generate the
-        <filename>errmsg.sys</filename> file:
+        You can also change the error messages produced by the server.
+        Details can be found in the MySQL Internals manual, available at
+        <ulink url="&base-url-docs;"/>. If you upgrade to a newer
+        version of MySQL after changing the error messages, remember to
+        repeat your changes after the upgrade.
       </para>
 
-<programlisting>
-shell&gt; <userinput>comp_err errmsg.txt errmsg.sys</userinput>
-</programlisting>
-
-      <para>
-        If you upgrade to a newer version of MySQL, remember to repeat
-        your changes with the new <filename>errmsg.txt</filename> file.
-      </para>
-
     </section>
 
     <section id="adding-character-set">

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-5.1/optimization.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -235,7 +235,7 @@
       <para>
         If you strive for database independence, you need to get a good
         feeling for each SQL server's bottlenecks. For example, MySQL is
-        very fast in retrieving and updating records for
+        very fast in retrieving and updating rows for
         <literal>MyISAM</literal> tables, but has a problem in mixing
         slow readers and writers on the same table. Oracle, on the other
         hand, has a big problem when you try to access rows that you
@@ -258,7 +258,7 @@
         system (such as the <literal>REPLACE</literal> statement, which
         is specific to MySQL), you should implement the same feature for
         other SQL servers by coding an alternative method. Although the
-        alternative might be slower, it allows the other servers to
+        alternative might be slower, it enables the other servers to
         perform the same tasks.
       </para>
 
@@ -534,13 +534,12 @@
 
       <para>
         You should definitely benchmark your application and database to
-        find out where the bottlenecks are. By fixing a bottleneck (or
-        by replacing it with a <quote>dummy</quote> module), you can
-        then proceed to identify the next bottleneck. Even if the
-        overall performance for your application currently is
-        acceptable, you should at least make a plan for each bottleneck
-        and decide how to solve it if someday you really need the extra
-        performance.
+        find out where the bottlenecks are. After fixing one bottleneck
+        (or by replacing it with a <quote>dummy</quote> module), you can
+        proceed to identify the next bottleneck. Even if the overall
+        performance for your application currently is acceptable, you
+        should at least make a plan for each bottleneck and decide how
+        to solve it if someday you really need the extra performance.
       </para>
 
       <para>
@@ -597,8 +596,8 @@
 
       <para>
         As suggested by the names of these programs, they can bring a
-        system to its knees, so make sure to use them
-        only on your development systems.
+        system to its knees, so make sure to use them only on your
+        development systems.
       </para>
 
     </section>
@@ -735,9 +734,11 @@
         <listitem>
           <para>
             When you precede a <literal>SELECT</literal> statement with
-            the keyword <literal>EXPLAIN</literal>, MySQL explains how
-            it would process the <literal>SELECT</literal>, providing
-            information about how tables are joined and in which order.
+            the keyword <literal>EXPLAIN</literal>, MySQL displays
+            information from the optimizer about the query execution
+            plan. That is, MySQL explains how it would process the
+            <literal>SELECT</literal>, including information about how
+            tables are joined and in which order.
           </para>
         </listitem>
 
@@ -746,39 +747,42 @@
       <remark role="help-description-end"/>
 
       <para>
-        This section provides information about the second use of
-        <literal>EXPLAIN</literal>.
+        This section describes the second use of
+        <literal>EXPLAIN</literal> for obtaining query execution plan
+        information. For a description of the
+        <literal>DESCRIBE</literal> and <literal>SHOW COLUMNS</literal>
+        statements, see <xref linkend="describe"/>, and
+        <xref linkend="show-columns"/>.
       </para>
 
       <para>
         With the help of <literal>EXPLAIN</literal>, you can see where
         you should add indexes to tables in order to get a faster
-        <literal>SELECT</literal> that uses indexes to find records.
+        <literal>SELECT</literal> that uses indexes to find rows. You
+        can also use <literal>EXPLAIN</literal> to see whether the
+        optimizer joins the tables in an optimal order. To force the
+        optimizer to use a join order corresponding to the order in
+        which the tables are named in the <literal>SELECT</literal>
+        statement, begin the statement with <literal>SELECT
+        STRAIGHT_JOIN</literal> rather than just
+        <literal>SELECT</literal>.
       </para>
 
       <para>
-        If you have a problem with incorrect index usage, you should run
-        <literal>ANALYZE TABLE</literal> to update table statistics such
-        as cardinality of keys, which can affect the choices the
-        optimizer makes. See <xref linkend="analyze-table"/>.
+        If you have a problem with indexes not being used when you
+        believe that they should be, you should run <literal>ANALYZE
+        TABLE</literal> to update table statistics such as cardinality
+        of keys, that can affect the choices the optimizer makes. See
+        <xref linkend="analyze-table"/>.
       </para>
 
       <para>
-        You can also see whether the optimizer joins the tables in an
-        optimal order. To force the optimizer to use a join order
-        corresponding to the order in which the tables are named in the
-        <literal>SELECT</literal> statement, begin the statement with
-        <literal>SELECT STRAIGHT_JOIN</literal> rather than just
-        <literal>SELECT</literal>.
-      </para>
-
-      <para>
         <literal>EXPLAIN</literal> returns a row of information for each
         table used in the <literal>SELECT</literal> statement. The
         tables are listed in the output in the order that MySQL would
         read them while processing the query. MySQL resolves all joins
         using a <firstterm>single-sweep multi-join</firstterm> method.
-        This means that MySQL reads a row from the first table, then
+        This means that MySQL reads a row from the first table, and then
         finds a matching row in the second table, the third table, and
         so on. When all tables are processed, MySQL outputs the selected
         columns and backtracks through the table list until a table is
@@ -1320,7 +1324,7 @@
             of the key that MySQL decided to use. The length is
             <literal>NULL</literal> if the <literal>key</literal> column
             says <literal>NULL</literal>. Note that the value of
-            <literal>key_len</literal> allows you to determine how many
+            <literal>key_len</literal> enables you to determine how many
             parts of a multiple-part key MySQL actually uses.
           </para>
         </listitem>
@@ -1421,7 +1425,7 @@
             <listitem>
               <para>
                 <literal>range checked for each record (index map:
-                #)</literal>
+                <replaceable>N</replaceable>)</literal>
               </para>
 
               <para>
@@ -1565,9 +1569,9 @@
                 cases, the condition is <quote>pushed down</quote> to
                 the cluster's data nodes where it is evaluated in all
                 partitions simultaneously. This eliminates the need to
-                send non-matching records over the network, and can
-                speed up such queries by a factor of 5 to 10 times over
-                cases where condition pushdown could be but is not used.
+                send non-matching rows over the network, and can speed
+                up such queries by a factor of 5 to 10 times over cases
+                where condition pushdown could be but is not used.
               </para>
 
               <para>
@@ -2024,9 +2028,9 @@
       </para>
 
       <para>
-        For writes, however, you need four seek requests (as above) to
-        find where to place the new index and normally two seeks to
-        update the index and write the row.
+        For writes, however, you need four seek requests to find where
+        to place the new index and normally two seeks to update the
+        index and write the row.
       </para>
 
       <para>
@@ -2100,9 +2104,9 @@
             <command>myisamchk --sort-index --sort-records=1</command>
             (if you want to sort on index 1). This is a good way to make
             queries faster if you have a unique index from which you
-            want to read all records in order according to the index.
-            Note that the first time you sort a large table this way, it
-            may take a long time.
+            want to read all rows in order according to the index. Note
+            that the first time you sort a large table this way, it may
+            take a long time.
           </para>
         </listitem>
 
@@ -2189,7 +2193,7 @@
             <literal>COUNT(*)</literal> on a single table without a
             <literal>WHERE</literal> is retrieved directly from the
             table information for <literal>MyISAM</literal> and
-            <literal>HEAP</literal> tables. This is also done for any
+            <literal>MEMORY</literal> tables. This is also done for any
             <literal>NOT NULL</literal> expression when used with only
             one table.
           </para>
@@ -2216,7 +2220,7 @@
           <para>
             For each table in a join, a simpler <literal>WHERE</literal>
             is constructed to get a fast <literal>WHERE</literal>
-            evaluation for the table and also to skip records as soon as
+            evaluation for the table and also to skip rows as soon as
             possible.
           </para>
         </listitem>
@@ -2318,7 +2322,7 @@
 
         <listitem>
           <para>
-            Before each record is output, those that do not match the
+            Before each row is output, those that do not match the
             <literal>HAVING</literal> clause are skipped.
           </para>
         </listitem>
@@ -2379,8 +2383,8 @@
 
       <para>
         The <literal>range</literal> access method uses a single index
-        to retrieve a subset of table records that are contained within
-        one or several index value intervals. It can be used for a
+        to retrieve a subset of table rows that are contained within one
+        or several index value intervals. It can be used for a
         single-part or multiple-part index. A detailed description of
         how intervals are extracted from the <literal>WHERE</literal>
         clause is given in the following sections.
@@ -2546,7 +2550,7 @@
               LIKE '%b'</literal> because they cannot be used for a
               range scan. The right way to remove them is to replace
               them with <literal>TRUE</literal>, so that we do not miss
-              any matching records when doing the range scan. Having
+              any matching rows when doing the range scan. Having
               replaced them with <literal>TRUE</literal>, we get:
             </para>
 
@@ -2635,8 +2639,8 @@
         <para>
           Range conditions on a multiple-part index are an extension of
           range conditions for a single-part index. A range condition on
-          a multiple-part index restricts index records to lie within
-          one or several key tuple intervals. Key tuple intervals are
+          a multiple-part index restricts index rows to lie within one
+          or several key tuple intervals. Key tuple intervals are
           defined over a set of key tuples, using ordering from the
           index.
         </para>
@@ -2744,7 +2748,7 @@
               <literal>'<replaceable>pattern</replaceable>'</literal>
               does not start with a wildcard). An interval can be used
               as long as it is possible to determine a single key tuple
-              containing all records that match the condition (or two
+              containing all rows that match the condition (or two
               intervals if <literal>&lt;&gt;</literal> or
               <literal>!=</literal> is used). For example, for this
               condition:
@@ -2766,7 +2770,7 @@
 
             <para>
               It is possible that the created interval contains more
-              records than the initial condition. For example, the
+              rows than the initial condition. For example, the
               preceding interval includes the value <literal>('foo', 11,
               0)</literal>, which does not satisfy the original
               condition.
@@ -2775,13 +2779,13 @@
 
           <listitem>
             <para>
-              If conditions that cover sets of records contained within
+              If conditions that cover sets of rows contained within
               intervals are combined with <literal>OR</literal>, they
-              form a condition that covers a set of records contained
+              form a condition that covers a set of rows contained
               within the union of their intervals. If the conditions are
               combined with <literal>AND</literal>, they form a
-              condition that covers a set of records contained within
-              the intersection of their intervals. For example, for this
+              condition that covers a set of rows contained within the
+              intersection of their intervals. For example, for this
               condition on a two-part index:
             </para>
 
@@ -3086,7 +3090,7 @@
 
         <para>
           If all columns used in the query are covered by the used
-          indexes, full table records are not retrieved and
+          indexes, full table rows are not retrieved and
           (<literal>EXPLAIN</literal> output contains <literal>Using
           index</literal> in <literal>Extra</literal> field in this
           case). Here is an example of such query:
@@ -3098,15 +3102,15 @@
 
         <para>
           If the used indexes don't cover all columns used in the query,
-          full records are retrieved only when the range conditions for
-          all used keys are satisfied.
+          full rows are retrieved only when the range conditions for all
+          used keys are satisfied.
         </para>
 
         <para>
           If one of the merged conditions is a condition over a primary
           key of an <literal>InnoDB</literal> or <literal>BDB</literal>
-          table, it is not used for record retrieval, but is used to
-          filter out records retrieved using other conditions.
+          table, it is not used for row retrieval, but is used to filter
+          out rows retrieved using other conditions.
         </para>
 
       </section>
@@ -3193,8 +3197,7 @@
         <para>
           The difference between the sort-union algorithm and the union
           algorithm is that the sort-union algorithm must first fetch
-          row IDs for all records and sort them before returning any
-          records.
+          row IDs for all rows and sort them before returning any rows.
         </para>
 
       </section>
@@ -3831,7 +3834,7 @@
       </para>
 
       <para>
-        Suppose we have a join query over 3 tables
+        Suppose that we have a join query over 3 tables
         <literal>T1,T2,T3</literal> of the form:
       </para>
 
@@ -4035,7 +4038,7 @@
         When discussing about nested-loop algorithm for inner joins, we
         omitted some details whose impact on the performance of query
         execution may be huge. We did not mention so-called
-        <quote>pushed-down</quote> conditions. Suppose our
+        <quote>pushed-down</quote> conditions. Suppose that our
         <literal>WHERE</literal> condition
         <literal>P(T1,T2,T3)</literal> can be represented by a
         conjunctive formula:
@@ -4178,12 +4181,12 @@
         join operation, it takes into consideration only the plans
         where, for each such operation, the outer tables are accessed
         before the inner tables. The optimizer options are limited
-        because only such plans allow us to execute queries with outer
+        because only such plans enables us to execute queries with outer
         joins operations by the nested loop schema.
       </para>
 
       <para>
-        Suppose we have a query of the form:
+        Suppose that we have a query of the form:
       </para>
 
 <programlisting>
@@ -4535,7 +4538,7 @@
           <para>
             The type of table index used does not store rows in order.
             For example, this is true for a <literal>HASH</literal>
-            index in a <literal>HEAP</literal> table.
+            index in a <literal>MEMORY</literal> table.
           </para>
         </listitem>
 
@@ -4729,7 +4732,7 @@
           The most efficient way is when the index is used to directly
           retrieve the group fields. With this access method, MySQL uses
           the property of some index types (for example, B-Trees) that
-          the keys are ordered. This property allows use of lookup
+          the keys are ordered. This property enables use of lookup
           groups in an index without having to consider all keys in the
           index that satisfy all <literal>WHERE</literal> conditions.
           This access method considers only a fraction of the keys in an
@@ -4792,8 +4795,9 @@
 
         <para>
           The following queries provide several examples that fall into
-          this category, assuming there is an index <literal>idx(c1, c2,
-          c3)</literal> on table <literal>t1(c1,c2,c3,c4)</literal>:
+          this category, assuming that there is an index
+          <literal>idx(c1,c2,c3)</literal> on table
+          <literal>t1(c1,c2,c3,c4)</literal>:
         </para>
 
 <programlisting>
@@ -4892,10 +4896,11 @@
         </para>
 
         <para>
-          The following queries do not work with the first method above,
-          but still work with the second index access method (assuming
-          we have the aforementioned index <literal>idx</literal> on
-          table <literal>t1</literal>):
+          The following queries do not work with the loose index scan
+          access method described earlier, but still work with the tight
+          index scan access method (assuming that there is an index
+          <literal>idx(c1,c2,c3)</literal> on table
+          <literal>t1(c1,c2,c3,c4)</literal>).
         </para>
 
         <itemizedlist>
@@ -5151,7 +5156,7 @@
       </indexterm>
 
       <para>
-        The time required for inserting a record is determined by the
+        The time required for inserting a row is determined by the
         following factors, where the numbers indicate approximate
         proportions:
       </para>
@@ -5178,7 +5183,7 @@
 
         <listitem>
           <para>
-            Inserting record: (1 x size of record)
+            Inserting row: (1 x size of row)
           </para>
         </listitem>
 
@@ -5449,10 +5454,10 @@
 
       <para>
         Note that for a <literal>MyISAM</literal> table that uses
-        dynamic record format, updating a record to a longer total
-        length may split the record. If you do this often, it is very
-        important to use <literal>OPTIMIZE TABLE</literal> occasionally.
-        See <xref linkend="optimize-table"/>.
+        dynamic row format, updating a row to a longer total length may
+        split the row. If you do this often, it is very important to use
+        <literal>OPTIMIZE TABLE</literal> occasionally. See
+        <xref linkend="optimize-table"/>.
       </para>
 
     </section>
@@ -5462,8 +5467,8 @@
       <title>&title-delete-speed;</title>
 
       <para>
-        The time required to delete individual records is exactly
-        proportional to the number of indexes. To delete records more
+        The time required to delete individual rows is exactly
+        proportional to the number of indexes. To delete rows more
         quickly, you can increase the size of the key cache. See
         <xref linkend="server-parameters"/>.
       </para>
@@ -5590,9 +5595,9 @@
             For <literal>MyISAM</literal> tables that change frequently,
             you should try to avoid all variable-length columns
             (<literal>VARCHAR</literal>, <literal>BLOB</literal>, and
-            <literal>TEXT</literal>). The table uses dynamic record
-            format if it includes even a single variable-length column.
-            See <xref linkend="storage-engines"/>.
+            <literal>TEXT</literal>). The table uses dynamic row format
+            if it includes even a single variable-length column. See
+            <xref linkend="storage-engines"/>.
           </para>
         </listitem>
 
@@ -5605,10 +5610,10 @@
             modern disks can read the entire row fast enough for most
             applications. The only cases where splitting up a table
             makes an appreciable difference is if it is a
-            <literal>MyISAM</literal> table using dynamic record format
-            (see above) that you can change to a fixed record size, or
-            if you very often need to scan the table but do not need
-            most of the columns. See <xref linkend="storage-engines"/>.
+            <literal>MyISAM</literal> table using dynamic row format
+            that you can change to a fixed row size, or if you very
+            often need to scan the table but do not need most of the
+            columns. See <xref linkend="storage-engines"/>.
           </para>
         </listitem>
 
@@ -5712,8 +5717,7 @@
           <para>
             Use <literal>INSERT DELAYED</literal> when you do not need
             to know when your data is written. This speeds things up
-            because many records can be written with a single disk
-            write.
+            because many rows can be written with a single disk write.
           </para>
         </listitem>
 
@@ -6046,9 +6050,9 @@
         is, you can insert rows into a <literal>MyISAM</literal> table
         at the same time other clients are reading from it. No conflict
         occurs if the data file contains no free blocks in the middle,
-        because in that case, records always are inserted at the end of
-        the data file. (Holes can result from rows having been deleted
-        from or updated in the middle of the table.) If there are holes,
+        because in that case, rows always are inserted at the end of the
+        data file. (Holes can result from rows having been deleted from
+        or updated in the middle of the table.) If there are holes,
         concurrent inserts are re-enabled automatically when all holes
         have been filled with new data.
       </para>
@@ -6057,9 +6061,8 @@
         If you want to perform many <literal>INSERT</literal> and
         <literal>SELECT</literal> operations on a table when concurrent
         inserts are not possible, you can insert rows in a temporary
-        table and update the real table with the records from the
-        temporary table once in a while. This can be done with the
-        following code:
+        table and update the real table with the rows from the temporary
+        table once in a while. This can be done with the following code:
       </para>
 
 <programlisting>
@@ -6645,7 +6648,7 @@
             For <literal>MyISAM</literal> tables, if you do not have any
             variable-length columns (<literal>VARCHAR</literal>,
             <literal>TEXT</literal>, or <literal>BLOB</literal>
-            columns), a fixed-size record format is used. This is faster
+            columns), a fixed-size row format is used. This is faster
             but unfortunately may waste some space. See
             <xref linkend="myisam-table-formats"/>. You can hint that
             you want to have fixed length rows even if you have
@@ -6659,7 +6662,7 @@
           <para>
             In MySQL/InnoDB, <literal>InnoDB</literal> tables use a more
             compact storage format. In earlier versions of MySQL,
-            <literal>InnoDB</literal> records contain some redundant
+            <literal>InnoDB</literal> rows contain some redundant
             information, such as the number of columns and the length of
             each column, even for fixed-size columns. By default, tables
             are created in the compact format
@@ -6839,9 +6842,8 @@
       </para>
 
       <para>
-        The <literal>MEMORY</literal> (<literal>HEAP</literal>) storage
-        engine uses hash indexes by default, but also supports B-tree
-        indexes.
+        The <literal>MEMORY</literal> storage engine uses hash indexes
+        by default, but also supports B-tree indexes.
       </para>
 
     </section>
@@ -6953,13 +6955,13 @@
 
       <para>
         Indexes are used to find rows with specific column values
-        quickly. Without an index, MySQL must begin with the first
-        record and then read through the entire table to find the
-        relevant rows. The larger the table, the more this costs. If the
-        table has an index for the columns in question, MySQL can
-        quickly determine the position to seek to in the middle of the
-        data file without having to look at all the data. If a table has
-        1,000 rows, this is at least 100 times faster than reading
+        quickly. Without an index, MySQL must begin with the first row
+        and then read through the entire table to find the relevant
+        rows. The larger the table, the more this costs. If the table
+        has an index for the columns in question, MySQL can quickly
+        determine the position to seek to in the middle of the data file
+        without having to look at all the data. If a table has 1,000
+        rows, this is at least 100 times faster than reading
         sequentially. Note that if you need to access most of the rows,
         it is faster to read sequentially, because this minimizes disk
         seeks.
@@ -7481,7 +7483,7 @@
         </itemizedlist>
 
         <para>
-          Shared access to the key cache allows the server to improve
+          Shared access to the key cache enables the server to improve
           throughput significantly.
         </para>
 
@@ -7497,8 +7499,8 @@
           compete for control structures that manage access to the key
           cache buffers. To reduce key cache access contention further,
           MySQL &current-series; also provides multiple key caches,
-          which allow you to assign different table indexes to different
-          key caches.
+          which enables you to assign different table indexes to
+          different key caches.
         </para>
 
         <para>
@@ -7933,9 +7935,9 @@
       <para>
         Storage engines collect statistics about tables for use by the
         optimizer. Table statistics are based on value groups, where a
-        value group is a set of records with the same key prefix value.
-        For optimizer purposes, an important statistic is the average
-        value group size.
+        value group is a set of rows with the same key prefix value. For
+        optimizer purposes, an important statistic is the average value
+        group size.
       </para>
 
       <para>
@@ -7980,10 +7982,10 @@
         which is the number of value groups. The <literal>SHOW
         INDEX</literal> statement displays a cardinality value based on
         <replaceable>N</replaceable>/<replaceable>S</replaceable>, where
-        <replaceable>N</replaceable> is the number of records in the
-        table and <replaceable>S</replaceable> is the average value
-        group size. That ratio yields an approximate number of value
-        groups in the table.
+        <replaceable>N</replaceable> is the number of rows in the table
+        and <replaceable>S</replaceable> is the average value group
+        size. That ratio yields an approximate number of value groups in
+        the table.
       </para>
 
       <para>
@@ -9412,9 +9414,9 @@
           <para>
             All joins are executed in a single pass, and most joins can
             be done without even using a temporary table. Most temporary
-            tables are memory-based (<literal>HEAP</literal>) tables.
-            Temporary tables with a large record length (calculated as
-            the sum of all column lengths) or that contain
+            tables are memory-based (<literal>MEMORY</literal>) tables.
+            Temporary tables with a large row length (calculated as the
+            sum of all column lengths) or that contain
             <literal>BLOB</literal> columns are stored on disk.
           </para>
 

Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-common/news-5.1.xml	2006-01-16 02:42:43 UTC (rev 847)
@@ -99,7 +99,7 @@
     </para>
 
     <itemizedlist>
-      
+
       <listitem>
         <para>
           Added the XML functions <literal>ExtractValue()</literal> and
@@ -109,7 +109,7 @@
           <literal>UpdateXML()</literal> replaces the element selected
           from a fragment of XML by an XPath expression supplied by the
           user with a second XML fragment (also user-supplied), and
-          returns the modified XML. See <xref linkend="xml-functions"/>.   
+          returns the modified XML. See <xref linkend="xml-functions"/>.
         </para>
       </listitem>
 
@@ -190,14 +190,10 @@
           <literal>LIST</literal> a value less than any specified in one
           of the table's partition definitions resulted in a server
           crash. In such cases, <command>mysqld</command> now returns
-
           <errortext>ERROR 1500 (HY000): Table has no partition for
-          value <replaceable>v</replaceable>
-
-          </errortext>
-
-          , where <replaceable>v</replaceable> is the out-of-range
-          value. (Bug #15819)
+          value <replaceable>v</replaceable> </errortext> , where
+          <replaceable>v</replaceable> is the out-of-range value. (Bug
+          #15819)
         </para>
       </listitem>
 
@@ -225,6 +221,15 @@
 
       <listitem>
         <para>
+          Added the <command>mysqlslap</command> program, which is
+          designed to emulate client load for a MySQL server and report
+          the timing of each stage. It works as if multiple clients are
+          accessing the server.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>
           Added the <option>--server-id</option> option to
           <command>mysqlbinlog</command> to enable only those events
           created by the server having the given server ID to be
@@ -327,11 +332,8 @@
 
         <para>
           Previously, attempting to do so would produce the error
-
           <errortext>All partitions must have unique names in the
-          table</errortext>
-
-          . (Bug #15521)
+          table</errortext> . (Bug #15521)
         </para>
       </listitem>
 

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-16 02:42:31 UTC (rev 846)
+++ trunk/refman-common/titles.en.ent	2006-01-16 02:42:43 UTC (rev 847)
@@ -365,7 +365,7 @@
 <!ENTITY title-example-user-variables "Using User Variables">
 <!ENTITY title-examples "Examples of Common Queries">
 <!ENTITY title-exists-and-not-exists-subqueries "<literal>EXISTS</literal> and <literal>NOT EXISTS</literal>">
-<!ENTITY title-explain "<literal>EXPLAIN</literal> Syntax (Get Information About a <literal>SELECT</literal>)">
+<!ENTITY title-explain "Optimizing Queries with <literal>EXPLAIN</literal>">
 <!ENTITY title-export-of-data "How to Export a Table or Query from Access to MySQL?">
 <!ENTITY title-extended-show "Extensions to <literal>SHOW</literal> Statements">
 <!ENTITY title-extending-mysql "Extending MySQL">
@@ -1396,7 +1396,7 @@
 <!ENTITY title-query-issues "Query-Related Issues">
 <!ENTITY title-query-log "The General Query Log">
 <!ENTITY title-query-results "What Results You Can Get from a Query">
-<!ENTITY title-query-speed "Optimizing <literal>SELECT</literal> Statements and Other Queries">
+<!ENTITY title-query-speed "Optimizing <literal>SELECT</literal> and Other Statements">
 <!ENTITY title-query-timeout "How to Set the QueryTimeout Value for ODBC Connections?">
 <!ENTITY title-quick-install "Source Installation Overview">
 <!ENTITY title-quick-standard-installation "Standard MySQL Installation Using a Binary Distribution">

Thread
svn commit - mysqldoc@docsrva: r847 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-commonpaul16 Jan