List:Commits« Previous MessageNext Message »
From:paul Date:January 15 2006 4:58am
Subject:svn commit - mysqldoc@docsrva: r840 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-15 05:58:40 +0100 (Sun, 15 Jan 2006)
New Revision: 840

Log:
 r6219@frost:  paul | 2006-01-14 22:55:20 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/optimization.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-common/titles.en.ent


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

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-15 04:58:22 UTC (rev 839)
+++ trunk/refman-4.1/optimization.xml	2006-01-15 04:58:40 UTC (rev 840)
@@ -18,7 +18,7 @@
     understanding of the entire system to be optimized. Although it may
     be possible to perform some local optimizations with little
     knowledge of your system or application, the more optimal you want
-    your system to become, the more you have to know about it.
+    your system to become, the more you must know about it.
   </para>
 
   <para>
@@ -34,14 +34,11 @@
 
     <para>
       The most important factor in making a system fast is its basic
-      design. You also need to know what kinds of things your system is
-      doing, and what your bottlenecks are.
+      design. You must also know what kinds of processing your system is
+      doing, and what its bottlenecks are. In most cases, system
+      bottlenecks arise from these sources:
     </para>
 
-    <para>
-      The most common system bottlenecks are:
-    </para>
-
     <itemizedlist>
 
       <listitem>
@@ -59,9 +56,9 @@
         <para>
           Disk reading and writing. When the disk is at the correct
           position, we need to read the data. With modern disks, one
-          disk delivers at least 10-20MB/s throughput. This is easier to
-          optimize than seeks because you can read in parallel from
-          multiple disks.
+          disk delivers at least 10&minus;20MB/s throughput. This is
+          easier to optimize than seeks because you can read in parallel
+          from multiple disks.
         </para>
       </listitem>
 
@@ -147,14 +144,17 @@
           <para>
             All calculated expressions return a value that can be used
             instead of signaling an error condition. For example, 1/0
-            returns <literal>NULL</literal>. (This behavior can be
-            changed by using the
-            <literal>ERROR_FOR_DIVISION_BY_ZERO</literal> SQL mode).
+            returns <literal>NULL</literal>.
           </para>
         </listitem>
 
       </itemizedlist>
 
+      <para>
+        To change the preceding behaviors, you can enable stricter data
+        handling by setting the server SQL mode appropriately.
+      </para>
+
       <remark role="todo">
         We should really drop this next paragraph. We get a lot of flack
         over stuff like this, which is quite possibly justified...
@@ -168,9 +168,9 @@
       </para>
 
       <para>
-        For more information about this, see
-        <xref linkend="constraints"/>, and <xref linkend="insert"/>, or
-        <xref linkend="server-sql-mode"/>.
+        For more information about data handling, see
+        <xref linkend="constraints"/>,
+        <xref linkend="server-sql-mode"/>, and <xref linkend="insert"/>.
       </para>
 
     </section>
@@ -194,60 +194,45 @@
 
       <para>
         Because all SQL servers implement different parts of standard
-        SQL, it takes work to write portable SQL applications. It is
-        very easy to achieve portability for very simple selects and
+        SQL, it takes work to write portable database applications. It
+        is very easy to achieve portability for very simple selects and
         inserts, but becomes more difficult the more capabilities you
         require. If you want an application that is fast with many
-        database systems, it becomes even harder!
+        database systems, it becomes even more difficult.
       </para>
 
       <para>
-        To make a complex application portable, you need to determine
-        which SQL servers it must work with, then determine what
-        features those servers support.
-      </para>
-
-      <para>
         All database systems have some weak points. That is, they have
         different design compromises that lead to different behavior.
       </para>
 
       <para>
-        You can use the MySQL <command>crash-me</command> program to
-        find functions, types, and limits that you can use with a
-        selection of database servers. <command>crash-me</command> does
-        not check for every possible feature, but it is still reasonably
-        comprehensive, performing about 450 tests.
+        To make a complex application portable, you need to determine
+        which SQL servers it must work with, and then determine what
+        features those servers support. You can use the MySQL
+        <command>crash-me</command> program to find functions, types,
+        and limits that you can use with a selection of database
+        servers. <command>crash-me</command> does not check for every
+        possible feature, but it is still reasonably comprehensive,
+        performing about 450 tests. An example of the type of
+        information <command>crash-me</command> can provide is that you
+        should not use column names that are longer than 18 characters
+        if you want to be able to use Informix or DB2.
       </para>
 
       <para>
-        An example of the type of information
-        <command>crash-me</command> can provide is that you should not
-        use column names that are longer than 18 characters if you want
-        to be able to use Informix or DB2.
-      </para>
-
-      <para>
         The <command>crash-me</command> program and the MySQL benchmarks
         are all very database independent. By taking a look at how they
-        are written, you can get a feeling for what you have to do to
-        make your own applications database independent. The programs
-        can be found in the <filename>sql-bench</filename> directory of
-        MySQL source distributions. They are written in Perl and use the
-        DBI database interface. Use of DBI in itself solves part of the
+        are written, you can get a feeling for what you must do to make
+        your own applications database independent. The programs can be
+        found in the <filename>sql-bench</filename> directory of MySQL
+        source distributions. They are written in Perl and use the DBI
+        database interface. Use of DBI in itself solves part of the
         portability problem because it provides database-independent
-        access methods.
+        access methods. See <xref linkend="mysql-benchmarks"/>.
       </para>
 
       <para>
-        For <command>crash-me</command> results, visit
-        <ulink url="http://dev.mysql.com/tech-resources/crash-me.php"/>.
-        See
-        <ulink url="http://dev.mysql.com/tech-resources/benchmarks/"/>
-        for the results from the benchmarks.
-      </para>
-
-      <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
@@ -255,17 +240,17 @@
         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
         have recently updated (until they are flushed to disk).
-        Transactional databases in general are not very good at
+        Transactional database systems in general are not very good at
         generating summary tables from log tables, because in this case
         row locking is almost useless.
       </para>
 
       <para>
         To make your application <emphasis>really</emphasis> database
-        independent, you need to define an easily extendable interface
-        through which you manipulate your data. As C++ is available on
-        most systems, it makes sense to use a C++ class-based interface
-        to the databases.
+        independent, you should define an easily extendable interface
+        through which you manipulate your data. For example, C++ is
+        available on most systems, so it makes sense to use a C++
+        class-based interface to the databases.
       </para>
 
       <para>
@@ -273,39 +258,40 @@
         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 may be slower, it allows the other servers to
+        alternative might be slower, it allows the other servers to
         perform the same tasks.
       </para>
 
       <para>
         With MySQL, you can use the <literal>/*! */</literal> syntax to
-        add MySQL-specific keywords to a query. The code inside
+        add MySQL-specific keywords to a statement. The code inside
         <literal>/* */</literal> is treated as a comment (and ignored)
-        by most other SQL servers.
+        by most other SQL servers. For information about writing
+        comments, see <xref linkend="comments"/>.
       </para>
 
       <para>
-        If high performance is more important than exactness, as in some
-        Web applications, it is possible to create an application layer
-        that caches all results to give you even higher performance. By
-        letting old results expire after a while, you can keep the cache
-        reasonably fresh. This provides a method to handle high load
-        spikes, in which case you can dynamically increase the cache and
-        set the expiration timeout higher until things get back to
-        normal.
+        If high performance is more important than exactness, as for
+        some Web applications, it is possible to create an application
+        layer that caches all results to give you even higher
+        performance. By letting old results expire after a while, you
+        can keep the cache reasonably fresh. This provides a method to
+        handle high load spikes, in which case you can dynamically
+        increase the cache size and set the expiration timeout higher
+        until things get back to normal.
       </para>
 
       <para>
         In this case, the table creation information should contain
-        information of the initial size of the cache and how often the
-        table should normally be refreshed.
+        information about the initial cache size and how often the table
+        should normally be refreshed.
       </para>
 
       <para>
-        An alternative to implementing an application cache is to use
-        the MySQL query cache. By enabling the query cache, the server
-        handles the details of determining whether a query result can be
-        reused. This simplifies your application. See
+        An attractive alternative to implementing an application cache
+        is to use the MySQL query cache. By enabling the query cache,
+        the server handles the details of determining whether a query
+        result can be reused. This simplifies your application. See
         <xref linkend="query-cache"/>.
       </para>
 
@@ -344,10 +330,10 @@
 
       <para>
         The volume of data was quite huge (about seven million summary
-        transactions per month), and we had data for 4-10 years that we
-        needed to present to the users. We got weekly requests from our
-        customers, who wanted instant access to new reports from this
-        data.
+        transactions per month), and we had data for 4&minus;10 years
+        that we needed to present to the users. We got weekly requests
+        from our customers, who wanted instant access to new reports
+        from this data.
       </para>
 
       <para>
@@ -407,17 +393,11 @@
       </indexterm>
 
       <para>
-        This section should contain a technical description of the MySQL
-        benchmark suite (as well as <command>crash-me</command>), but
-        that description has not yet been written. However, you can get
-        a good idea for how the benchmarks work by looking at the code
-        and results in the <filename>sql-bench</filename> directory in
-        any MySQL source distribution.
-      </para>
-
-      <para>
         This benchmark suite is meant to tell any user what operations a
-        given SQL implementation performs well or poorly.
+        given SQL implementation performs well or poorly. You can get a
+        good idea for how the benchmarks work by looking at the code and
+        results in the <filename>sql-bench</filename> directory in any
+        MySQL source distribution.
       </para>
 
       <para>
@@ -438,8 +418,8 @@
             The benchmark suite is provided with MySQL source
             distributions. You can either download a released
             distribution from <ulink url="&base-url-downloads;"/>, or
-            use the current development source tree (see
-            <xref linkend="installing-source-tree"/>).
+            use the current development source tree. (See
+            <xref linkend="installing-source-tree"/>.)
           </para>
         </listitem>
 
@@ -461,9 +441,10 @@
       <para>
         After you obtain a MySQL source distribution, you can find the
         benchmark suite located in its <filename>sql-bench</filename>
-        directory. To run the benchmark tests, build MySQL, then change
-        location into the <filename>sql-bench</filename> directory and
-        execute the <literal>run-all-tests</literal> script:
+        directory. To run the benchmark tests, build MySQL, and then
+        change location into the <filename>sql-bench</filename>
+        directory and execute the <literal>run-all-tests</literal>
+        script:
       </para>
 
 <programlisting>
@@ -472,9 +453,9 @@
 </programlisting>
 
       <para>
-        <replaceable>server_name</replaceable> is one of the supported
-        servers. To get a list of all options and supported servers,
-        invoke this command:
+        <replaceable>server_name</replaceable> should be the name of one
+        of the supported servers. To get a list of all options and
+        supported servers, invoke this command:
       </para>
 
 <programlisting>
@@ -489,8 +470,9 @@
         The <command>crash-me</command> script also is located in the
         <filename>sql-bench</filename> directory.
         <command>crash-me</command> tries to determine what features a
-        database supports and what its capabilities and limitations are
-        by actually running queries. For example, it determines:
+        database system supports and what its capabilities and
+        limitations are by actually running queries. For example, it
+        determines:
       </para>
 
       <itemizedlist>
@@ -773,12 +755,12 @@
         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
-        finds a matching row in the second table, then in 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 found for which there are more matching rows. The
-        next row is read from this table and the process continues with
-        the next table.
+        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
+        found for which there are more matching rows. The next row is
+        read from this table and the process continues with the next
+        table.
       </para>
 
       <para>
@@ -4569,8 +4551,8 @@
 
       <para>
         When a lock is released, the lock is made available to the
-        threads in the write lock queue, then to the threads in the read
-        lock queue.
+        threads in the write lock queue, and then to the threads in the
+        read lock queue.
       </para>
 
       <para>
@@ -5492,7 +5474,7 @@
         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, then this is at least 100 times faster than reading
+        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.
@@ -6184,8 +6166,8 @@
         <para>
           One reason the use of three key caches is beneficial is that
           access to one key cache structure does not block access to the
-          others. Queries that access tables assigned to one cache do
-          not compete with queries that access tables assigned to
+          others. Statements that access tables assigned to one cache do
+          not compete with statements that access tables assigned to
           another cache. Performance gains occur for other reasons as
           well:
         </para>
@@ -6351,10 +6333,10 @@
         <para>
           If there are enough blocks in a key cache to hold blocks of an
           entire index, or at least the blocks corresponding to its
-          non-leaf nodes, then it makes sense to preload the key cache
-          with index blocks before starting to use it. Preloading allows
-          you to put the table index blocks into a key cache buffer in
-          the most efficient way: by reading the index blocks from disk
+          non-leaf nodes, it makes sense to preload the key cache with
+          index blocks before starting to use it. Preloading allows you
+          to put the table index blocks into a key cache buffer in the
+          most efficient way: by reading the index blocks from disk
           sequentially.
         </para>
 
@@ -7450,7 +7432,7 @@
 
       <para>
         By using a better compiler and compilation options, you can
-        obtain a 10-30% speed increase in applications. This is
+        obtain a 10&minus;30% speed increase in applications. This is
         particularly important if you compile the MySQL server yourself.
       </para>
 
@@ -7519,8 +7501,8 @@
         <listitem>
           <para>
             For TCP/IP connections from a client to a server, connecting
-            to a remote server on another host is 8-11% slower than
-            connecting to a server on the same host, even for
+            to a remote server on another host is 8&minus;11% slower
+            than connecting to a server on the same host, even for
             connections over 100Mb/s Ethernet.
           </para>
         </listitem>
@@ -7573,9 +7555,9 @@
 
         <listitem>
           <para>
-            On Solaris 2.5.1, MIT-pthreads is 8-12% slower than Solaris
-            native threads on a single processor. With greater loads or
-            more CPUs, the difference should be larger.
+            On Solaris 2.5.1, MIT-pthreads is 8&minus;12% slower than
+            Solaris native threads on a single processor. With greater
+            loads or more CPUs, the difference should be larger.
           </para>
         </listitem>
 
@@ -7584,7 +7566,7 @@
             Compiling on Linux-x86 using <command>gcc</command> without
             frame pointers (<option>-fomit-frame-pointer</option> or
             <option>-fomit-frame-pointer -ffixed-ebp</option>) makes
-            <command>mysqld</command> 1-4% faster.
+            <command>mysqld</command> 1&minus;4% faster.
           </para>
         </listitem>
 

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-15 04:58:22 UTC (rev 839)
+++ trunk/refman-5.0/optimization.xml	2006-01-15 04:58:40 UTC (rev 840)
@@ -18,7 +18,7 @@
     understanding of the entire system to be optimized. Although it may
     be possible to perform some local optimizations with little
     knowledge of your system or application, the more optimal you want
-    your system to become, the more you have to know about it.
+    your system to become, the more you must know about it.
   </para>
 
   <para>
@@ -34,14 +34,11 @@
 
     <para>
       The most important factor in making a system fast is its basic
-      design. You also need to know what kinds of things your system is
-      doing, and what your bottlenecks are.
+      design. You must also know what kinds of processing your system is
+      doing, and what its bottlenecks are. In most cases, system
+      bottlenecks arise from these sources:
     </para>
 
-    <para>
-      The most common system bottlenecks are:
-    </para>
-
     <itemizedlist>
 
       <listitem>
@@ -59,9 +56,9 @@
         <para>
           Disk reading and writing. When the disk is at the correct
           position, we need to read the data. With modern disks, one
-          disk delivers at least 10-20MB/s throughput. This is easier to
-          optimize than seeks because you can read in parallel from
-          multiple disks.
+          disk delivers at least 10&minus;20MB/s throughput. This is
+          easier to optimize than seeks because you can read in parallel
+          from multiple disks.
         </para>
       </listitem>
 
@@ -115,8 +112,8 @@
         non-transactional tables (which cannot roll back if something
         goes wrong), MySQL has the following rules. Note that these
         rules apply <emphasis>only</emphasis> when not running in strict
-        mode or if you use the <literal>IGNORE</literal> specifier for
-        <literal>INSERT</literal> or <literal>UPDATE</literal>.
+        SQL mode or if you use the <literal>IGNORE</literal> specifier
+        for <literal>INSERT</literal> or <literal>UPDATE</literal>.
       </para>
 
       <indexterm>
@@ -127,10 +124,7 @@
 
         <listitem>
           <para>
-            All columns have default values. Note that when running in
-            strict SQL mode (including <literal>TRADITIONAL</literal>
-            SQL mode), you must specify any default value for a
-            <literal>NOT NULL</literal> column.
+            All columns have default values.
           </para>
         </listitem>
 
@@ -142,9 +136,7 @@
             values, this is 0, the smallest possible value or the
             largest possible value. For strings, this is either the
             empty string or as much of the string as can be stored in
-            the column. Note that this behavior does not apply when
-            running in strict or <literal>TRADITIONAL</literal> SQL
-            mode.
+            the column.
           </para>
         </listitem>
 
@@ -152,14 +144,17 @@
           <para>
             All calculated expressions return a value that can be used
             instead of signaling an error condition. For example, 1/0
-            returns <literal>NULL</literal>. (This behavior can be
-            changed by using the
-            <literal>ERROR_FOR_DIVISION_BY_ZERO</literal> SQL mode).
+            returns <literal>NULL</literal>.
           </para>
         </listitem>
 
       </itemizedlist>
 
+      <para>
+        To change the preceding behaviors, you can enable stricter data
+        handling by setting the server SQL mode appropriately.
+      </para>
+
       <remark role="todo">
         We should really drop this next paragraph. We get a lot of flack
         over stuff like this, which is quite possibly justified...
@@ -173,9 +168,9 @@
       </para>
 
       <para>
-        For more information about this, see
-        <xref linkend="constraints"/>, and <xref linkend="insert"/>, or
-        <xref linkend="server-sql-mode"/>.
+        For more information about data handling, see
+        <xref linkend="constraints"/>,
+        <xref linkend="server-sql-mode"/>, and <xref linkend="insert"/>.
       </para>
 
     </section>
@@ -199,60 +194,45 @@
 
       <para>
         Because all SQL servers implement different parts of standard
-        SQL, it takes work to write portable SQL applications. It is
-        very easy to achieve portability for very simple selects and
+        SQL, it takes work to write portable database applications. It
+        is very easy to achieve portability for very simple selects and
         inserts, but becomes more difficult the more capabilities you
         require. If you want an application that is fast with many
-        database systems, it becomes even harder!
+        database systems, it becomes even more difficult.
       </para>
 
       <para>
-        To make a complex application portable, you need to determine
-        which SQL servers it must work with, then determine what
-        features those servers support.
-      </para>
-
-      <para>
         All database systems have some weak points. That is, they have
         different design compromises that lead to different behavior.
       </para>
 
       <para>
-        You can use the MySQL <command>crash-me</command> program to
-        find functions, types, and limits that you can use with a
-        selection of database servers. <command>crash-me</command> does
-        not check for every possible feature, but it is still reasonably
-        comprehensive, performing about 450 tests.
+        To make a complex application portable, you need to determine
+        which SQL servers it must work with, and then determine what
+        features those servers support. You can use the MySQL
+        <command>crash-me</command> program to find functions, types,
+        and limits that you can use with a selection of database
+        servers. <command>crash-me</command> does not check for every
+        possible feature, but it is still reasonably comprehensive,
+        performing about 450 tests. An example of the type of
+        information <command>crash-me</command> can provide is that you
+        should not use column names that are longer than 18 characters
+        if you want to be able to use Informix or DB2.
       </para>
 
       <para>
-        An example of the type of information
-        <command>crash-me</command> can provide is that you should not
-        use column names that are longer than 18 characters if you want
-        to be able to use Informix or DB2.
-      </para>
-
-      <para>
         The <command>crash-me</command> program and the MySQL benchmarks
         are all very database independent. By taking a look at how they
-        are written, you can get a feeling for what you have to do to
-        make your own applications database independent. The programs
-        can be found in the <filename>sql-bench</filename> directory of
-        MySQL source distributions. They are written in Perl and use the
-        DBI database interface. Use of DBI in itself solves part of the
+        are written, you can get a feeling for what you must do to make
+        your own applications database independent. The programs can be
+        found in the <filename>sql-bench</filename> directory of MySQL
+        source distributions. They are written in Perl and use the DBI
+        database interface. Use of DBI in itself solves part of the
         portability problem because it provides database-independent
-        access methods.
+        access methods. See <xref linkend="mysql-benchmarks"/>.
       </para>
 
       <para>
-        For <command>crash-me</command> results, visit
-        <ulink url="http://dev.mysql.com/tech-resources/crash-me.php"/>.
-        See
-        <ulink url="http://dev.mysql.com/tech-resources/benchmarks/"/>
-        for the results from the benchmarks.
-      </para>
-
-      <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
@@ -260,17 +240,17 @@
         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
         have recently updated (until they are flushed to disk).
-        Transactional databases in general are not very good at
+        Transactional database systems in general are not very good at
         generating summary tables from log tables, because in this case
         row locking is almost useless.
       </para>
 
       <para>
         To make your application <emphasis>really</emphasis> database
-        independent, you need to define an easily extendable interface
-        through which you manipulate your data. As C++ is available on
-        most systems, it makes sense to use a C++ class-based interface
-        to the databases.
+        independent, you should define an easily extendable interface
+        through which you manipulate your data. For example, C++ is
+        available on most systems, so it makes sense to use a C++
+        class-based interface to the databases.
       </para>
 
       <para>
@@ -278,39 +258,40 @@
         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 may be slower, it allows the other servers to
+        alternative might be slower, it allows the other servers to
         perform the same tasks.
       </para>
 
       <para>
         With MySQL, you can use the <literal>/*! */</literal> syntax to
-        add MySQL-specific keywords to a query. The code inside
+        add MySQL-specific keywords to a statement. The code inside
         <literal>/* */</literal> is treated as a comment (and ignored)
-        by most other SQL servers.
+        by most other SQL servers. For information about writing
+        comments, see <xref linkend="comments"/>.
       </para>
 
       <para>
-        If high performance is more important than exactness, as in some
-        Web applications, it is possible to create an application layer
-        that caches all results to give you even higher performance. By
-        letting old results expire after a while, you can keep the cache
-        reasonably fresh. This provides a method to handle high load
-        spikes, in which case you can dynamically increase the cache and
-        set the expiration timeout higher until things get back to
-        normal.
+        If high performance is more important than exactness, as for
+        some Web applications, it is possible to create an application
+        layer that caches all results to give you even higher
+        performance. By letting old results expire after a while, you
+        can keep the cache reasonably fresh. This provides a method to
+        handle high load spikes, in which case you can dynamically
+        increase the cache size and set the expiration timeout higher
+        until things get back to normal.
       </para>
 
       <para>
         In this case, the table creation information should contain
-        information of the initial size of the cache and how often the
-        table should normally be refreshed.
+        information about the initial cache size and how often the table
+        should normally be refreshed.
       </para>
 
       <para>
-        An alternative to implementing an application cache is to use
-        the MySQL query cache. By enabling the query cache, the server
-        handles the details of determining whether a query result can be
-        reused. This simplifies your application. See
+        An attractive alternative to implementing an application cache
+        is to use the MySQL query cache. By enabling the query cache,
+        the server handles the details of determining whether a query
+        result can be reused. This simplifies your application. See
         <xref linkend="query-cache"/>.
       </para>
 
@@ -349,10 +330,10 @@
 
       <para>
         The volume of data was quite huge (about seven million summary
-        transactions per month), and we had data for 4-10 years that we
-        needed to present to the users. We got weekly requests from our
-        customers, who wanted instant access to new reports from this
-        data.
+        transactions per month), and we had data for 4&minus;10 years
+        that we needed to present to the users. We got weekly requests
+        from our customers, who wanted instant access to new reports
+        from this data.
       </para>
 
       <para>
@@ -412,17 +393,11 @@
       </indexterm>
 
       <para>
-        This section should contain a technical description of the MySQL
-        benchmark suite (as well as <command>crash-me</command>), but
-        that description has not yet been written. However, you can get
-        a good idea for how the benchmarks work by looking at the code
-        and results in the <filename>sql-bench</filename> directory in
-        any MySQL source distribution.
-      </para>
-
-      <para>
         This benchmark suite is meant to tell any user what operations a
-        given SQL implementation performs well or poorly.
+        given SQL implementation performs well or poorly. You can get a
+        good idea for how the benchmarks work by looking at the code and
+        results in the <filename>sql-bench</filename> directory in any
+        MySQL source distribution.
       </para>
 
       <para>
@@ -443,8 +418,8 @@
             The benchmark suite is provided with MySQL source
             distributions. You can either download a released
             distribution from <ulink url="&base-url-downloads;"/>, or
-            use the current development source tree (see
-            <xref linkend="installing-source-tree"/>).
+            use the current development source tree. (See
+            <xref linkend="installing-source-tree"/>.)
           </para>
         </listitem>
 
@@ -466,9 +441,10 @@
       <para>
         After you obtain a MySQL source distribution, you can find the
         benchmark suite located in its <filename>sql-bench</filename>
-        directory. To run the benchmark tests, build MySQL, then change
-        location into the <filename>sql-bench</filename> directory and
-        execute the <literal>run-all-tests</literal> script:
+        directory. To run the benchmark tests, build MySQL, and then
+        change location into the <filename>sql-bench</filename>
+        directory and execute the <literal>run-all-tests</literal>
+        script:
       </para>
 
 <programlisting>
@@ -477,9 +453,9 @@
 </programlisting>
 
       <para>
-        <replaceable>server_name</replaceable> is one of the supported
-        servers. To get a list of all options and supported servers,
-        invoke this command:
+        <replaceable>server_name</replaceable> should be the name of one
+        of the supported servers. To get a list of all options and
+        supported servers, invoke this command:
       </para>
 
 <programlisting>
@@ -494,8 +470,9 @@
         The <command>crash-me</command> script also is located in the
         <filename>sql-bench</filename> directory.
         <command>crash-me</command> tries to determine what features a
-        database supports and what its capabilities and limitations are
-        by actually running queries. For example, it determines:
+        database system supports and what its capabilities and
+        limitations are by actually running queries. For example, it
+        determines:
       </para>
 
       <itemizedlist>
@@ -778,12 +755,12 @@
         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
-        finds a matching row in the second table, then in 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 found for which there are more matching rows. The
-        next row is read from this table and the process continues with
-        the next table.
+        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
+        found for which there are more matching rows. The next row is
+        read from this table and the process continues with the next
+        table.
       </para>
 
       <para>
@@ -3948,11 +3925,11 @@
         before the loop and is checked after the loop. The flag is
         turned on when for the current row from the outer table a match
         from the table representing the inner operand is found. If at
-        the end of the loop cycle the flag is still off, then no match
-        has been found for the current row of the outer table. In this
-        case, the row is complemented by <literal>NULL</literal> values
-        for the columns of the inner tables. The result row is passed to
-        the final check for the output or into the next nested loop, but
+        the end of the loop cycle the flag is still off, no match has
+        been found for the current row of the outer table. In this case,
+        the row is complemented by <literal>NULL</literal> values for
+        the columns of the inner tables. The result row is passed to the
+        final check for the output or into the next nested loop, but
         only if the row satisfies the join condition of all embedded
         outer joins.
       </para>
@@ -4786,7 +4763,7 @@
               The <literal>GROUP BY</literal> includes the first
               consecutive parts of the index (if instead of
               <literal>GROUP BY</literal>, the query has a
-              <literal>DISTINCT</literal> clause, then all distinct
+              <literal>DISTINCT</literal> clause, all distinct
               attributes refer to the beginning of the index).
             </para>
           </listitem>
@@ -6037,8 +6014,8 @@
 
       <para>
         When a lock is released, the lock is made available to the
-        threads in the write lock queue, then to the threads in the read
-        lock queue.
+        threads in the write lock queue, and then to the threads in the
+        read lock queue.
       </para>
 
       <para>
@@ -6988,7 +6965,7 @@
         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, then this is at least 100 times faster than reading
+        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.
@@ -7650,8 +7627,8 @@
         <para>
           One reason the use of three key caches is beneficial is that
           access to one key cache structure does not block access to the
-          others. Queries that access tables assigned to one cache do
-          not compete with queries that access tables assigned to
+          others. Statements that access tables assigned to one cache do
+          not compete with statements that access tables assigned to
           another cache. Performance gains occur for other reasons as
           well:
         </para>
@@ -7822,10 +7799,10 @@
         <para>
           If there are enough blocks in a key cache to hold blocks of an
           entire index, or at least the blocks corresponding to its
-          non-leaf nodes, then it makes sense to preload the key cache
-          with index blocks before starting to use it. Preloading allows
-          you to put the table index blocks into a key cache buffer in
-          the most efficient way: by reading the index blocks from disk
+          non-leaf nodes, it makes sense to preload the key cache with
+          index blocks before starting to use it. Preloading allows you
+          to put the table index blocks into a key cache buffer in the
+          most efficient way: by reading the index blocks from disk
           sequentially.
         </para>
 
@@ -8925,10 +8902,10 @@
         possible query evaluation plans. For join queries, the number of
         possible plans investigated by the MySQL optimizer grows
         exponentially with the number of tables referenced in a query.
-        For small numbers of tables (typically less than 7-10) this is
-        not a problem. However, when bigger queries are submitted, the
-        time spent in query optimization may easily become the major
-        bottleneck in the server's performance.
+        For small numbers of tables (typically less than 7&minus;10)
+        this is not a problem. However, when bigger queries are
+        submitted, the time spent in query optimization may easily
+        become the major bottleneck in the server's performance.
       </para>
 
       <para>
@@ -8958,7 +8935,7 @@
             compilation times. That is why this option is on
             (<literal>optimizer_prune_level</literal>=1) by default.
             However, if you believe that the optimizer missed a better
-            query plan, then this option can be switched off
+            query plan, this option can be switched off
             (<literal>optimizer_prune_level</literal>=0) with the risk
             that query compilation may take much longer. Notice that
             even with the use of this heuristic, the optimizer still
@@ -9044,7 +9021,7 @@
 
       <para>
         By using a better compiler and compilation options, you can
-        obtain a 10-30% speed increase in applications. This is
+        obtain a 10&minus;30% speed increase in applications. This is
         particularly important if you compile the MySQL server yourself.
       </para>
 
@@ -9113,8 +9090,8 @@
         <listitem>
           <para>
             For TCP/IP connections from a client to a server, connecting
-            to a remote server on another host is 8-11% slower than
-            connecting to a server on the same host, even for
+            to a remote server on another host is 8&minus;11% slower
+            than connecting to a server on the same host, even for
             connections over 100Mb/s Ethernet.
           </para>
         </listitem>
@@ -9167,9 +9144,9 @@
 
         <listitem>
           <para>
-            On Solaris 2.5.1, MIT-pthreads is 8-12% slower than Solaris
-            native threads on a single processor. With greater loads or
-            more CPUs, the difference should be larger.
+            On Solaris 2.5.1, MIT-pthreads is 8&minus;12% slower than
+            Solaris native threads on a single processor. With greater
+            loads or more CPUs, the difference should be larger.
           </para>
         </listitem>
 
@@ -9178,7 +9155,7 @@
             Compiling on Linux-x86 using <command>gcc</command> without
             frame pointers (<option>-fomit-frame-pointer</option> or
             <option>-fomit-frame-pointer -ffixed-ebp</option>) makes
-            <command>mysqld</command> 1-4% faster.
+            <command>mysqld</command> 1&minus;4% faster.
           </para>
         </listitem>
 

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-15 04:58:22 UTC (rev 839)
+++ trunk/refman-5.1/optimization.xml	2006-01-15 04:58:40 UTC (rev 840)
@@ -18,7 +18,7 @@
     understanding of the entire system to be optimized. Although it may
     be possible to perform some local optimizations with little
     knowledge of your system or application, the more optimal you want
-    your system to become, the more you have to know about it.
+    your system to become, the more you must know about it.
   </para>
 
   <para>
@@ -34,14 +34,11 @@
 
     <para>
       The most important factor in making a system fast is its basic
-      design. You also need to know what kinds of things your system is
-      doing, and what your bottlenecks are.
+      design. You must also know what kinds of processing your system is
+      doing, and what its bottlenecks are. In most cases, system
+      bottlenecks arise from these sources:
     </para>
 
-    <para>
-      The most common system bottlenecks are:
-    </para>
-
     <itemizedlist>
 
       <listitem>
@@ -59,9 +56,9 @@
         <para>
           Disk reading and writing. When the disk is at the correct
           position, we need to read the data. With modern disks, one
-          disk delivers at least 10-20MB/s throughput. This is easier to
-          optimize than seeks because you can read in parallel from
-          multiple disks.
+          disk delivers at least 10&minus;20MB/s throughput. This is
+          easier to optimize than seeks because you can read in parallel
+          from multiple disks.
         </para>
       </listitem>
 
@@ -115,8 +112,8 @@
         non-transactional tables (which cannot roll back if something
         goes wrong), MySQL has the following rules. Note that these
         rules apply <emphasis>only</emphasis> when not running in strict
-        mode or if you use the <literal>IGNORE</literal> specifier for
-        <literal>INSERT</literal> or <literal>UPDATE</literal>.
+        SQL mode or if you use the <literal>IGNORE</literal> specifier
+        for <literal>INSERT</literal> or <literal>UPDATE</literal>.
       </para>
 
       <indexterm>
@@ -127,10 +124,7 @@
 
         <listitem>
           <para>
-            All columns have default values. Note that when running in
-            strict SQL mode (including <literal>TRADITIONAL</literal>
-            SQL mode), you must specify any default value for a
-            <literal>NOT NULL</literal> column.
+            All columns have default values.
           </para>
         </listitem>
 
@@ -142,9 +136,7 @@
             values, this is 0, the smallest possible value or the
             largest possible value. For strings, this is either the
             empty string or as much of the string as can be stored in
-            the column. Note that this behavior does not apply when
-            running in strict or <literal>TRADITIONAL</literal> SQL
-            mode.
+            the column.
           </para>
         </listitem>
 
@@ -152,14 +144,17 @@
           <para>
             All calculated expressions return a value that can be used
             instead of signaling an error condition. For example, 1/0
-            returns <literal>NULL</literal>. (This behavior can be
-            changed by using the
-            <literal>ERROR_FOR_DIVISION_BY_ZERO</literal> SQL mode).
+            returns <literal>NULL</literal>.
           </para>
         </listitem>
 
       </itemizedlist>
 
+      <para>
+        To change the preceding behaviors, you can enable stricter data
+        handling by setting the server SQL mode appropriately.
+      </para>
+
       <remark role="todo">
         We should really drop this next paragraph. We get a lot of flack
         over stuff like this, which is quite possibly justified...
@@ -173,9 +168,9 @@
       </para>
 
       <para>
-        For more information about this, see
-        <xref linkend="constraints"/>, and <xref linkend="insert"/>, or
-        <xref linkend="server-sql-mode"/>.
+        For more information about data handling, see
+        <xref linkend="constraints"/>,
+        <xref linkend="server-sql-mode"/>, and <xref linkend="insert"/>.
       </para>
 
     </section>
@@ -199,60 +194,45 @@
 
       <para>
         Because all SQL servers implement different parts of standard
-        SQL, it takes work to write portable SQL applications. It is
-        very easy to achieve portability for very simple selects and
+        SQL, it takes work to write portable database applications. It
+        is very easy to achieve portability for very simple selects and
         inserts, but becomes more difficult the more capabilities you
         require. If you want an application that is fast with many
-        database systems, it becomes even harder!
+        database systems, it becomes even more difficult.
       </para>
 
       <para>
-        To make a complex application portable, you need to determine
-        which SQL servers it must work with, then determine what
-        features those servers support.
-      </para>
-
-      <para>
         All database systems have some weak points. That is, they have
         different design compromises that lead to different behavior.
       </para>
 
       <para>
-        You can use the MySQL <command>crash-me</command> program to
-        find functions, types, and limits that you can use with a
-        selection of database servers. <command>crash-me</command> does
-        not check for every possible feature, but it is still reasonably
-        comprehensive, performing about 450 tests.
+        To make a complex application portable, you need to determine
+        which SQL servers it must work with, and then determine what
+        features those servers support. You can use the MySQL
+        <command>crash-me</command> program to find functions, types,
+        and limits that you can use with a selection of database
+        servers. <command>crash-me</command> does not check for every
+        possible feature, but it is still reasonably comprehensive,
+        performing about 450 tests. An example of the type of
+        information <command>crash-me</command> can provide is that you
+        should not use column names that are longer than 18 characters
+        if you want to be able to use Informix or DB2.
       </para>
 
       <para>
-        An example of the type of information
-        <command>crash-me</command> can provide is that you should not
-        use column names that are longer than 18 characters if you want
-        to be able to use Informix or DB2.
-      </para>
-
-      <para>
         The <command>crash-me</command> program and the MySQL benchmarks
         are all very database independent. By taking a look at how they
-        are written, you can get a feeling for what you have to do to
-        make your own applications database independent. The programs
-        can be found in the <filename>sql-bench</filename> directory of
-        MySQL source distributions. They are written in Perl and use the
-        DBI database interface. Use of DBI in itself solves part of the
+        are written, you can get a feeling for what you must do to make
+        your own applications database independent. The programs can be
+        found in the <filename>sql-bench</filename> directory of MySQL
+        source distributions. They are written in Perl and use the DBI
+        database interface. Use of DBI in itself solves part of the
         portability problem because it provides database-independent
-        access methods.
+        access methods. See <xref linkend="mysql-benchmarks"/>.
       </para>
 
       <para>
-        For <command>crash-me</command> results, visit
-        <ulink url="http://dev.mysql.com/tech-resources/crash-me.php"/>.
-        See
-        <ulink url="http://dev.mysql.com/tech-resources/benchmarks/"/>
-        for the results from the benchmarks.
-      </para>
-
-      <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
@@ -260,17 +240,17 @@
         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
         have recently updated (until they are flushed to disk).
-        Transactional databases in general are not very good at
+        Transactional database systems in general are not very good at
         generating summary tables from log tables, because in this case
         row locking is almost useless.
       </para>
 
       <para>
         To make your application <emphasis>really</emphasis> database
-        independent, you need to define an easily extendable interface
-        through which you manipulate your data. As C++ is available on
-        most systems, it makes sense to use a C++ class-based interface
-        to the databases.
+        independent, you should define an easily extendable interface
+        through which you manipulate your data. For example, C++ is
+        available on most systems, so it makes sense to use a C++
+        class-based interface to the databases.
       </para>
 
       <para>
@@ -278,39 +258,40 @@
         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 may be slower, it allows the other servers to
+        alternative might be slower, it allows the other servers to
         perform the same tasks.
       </para>
 
       <para>
         With MySQL, you can use the <literal>/*! */</literal> syntax to
-        add MySQL-specific keywords to a query. The code inside
+        add MySQL-specific keywords to a statement. The code inside
         <literal>/* */</literal> is treated as a comment (and ignored)
-        by most other SQL servers.
+        by most other SQL servers. For information about writing
+        comments, see <xref linkend="comments"/>.
       </para>
 
       <para>
-        If high performance is more important than exactness, as in some
-        Web applications, it is possible to create an application layer
-        that caches all results to give you even higher performance. By
-        letting old results expire after a while, you can keep the cache
-        reasonably fresh. This provides a method to handle high load
-        spikes, in which case you can dynamically increase the cache and
-        set the expiration timeout higher until things get back to
-        normal.
+        If high performance is more important than exactness, as for
+        some Web applications, it is possible to create an application
+        layer that caches all results to give you even higher
+        performance. By letting old results expire after a while, you
+        can keep the cache reasonably fresh. This provides a method to
+        handle high load spikes, in which case you can dynamically
+        increase the cache size and set the expiration timeout higher
+        until things get back to normal.
       </para>
 
       <para>
         In this case, the table creation information should contain
-        information of the initial size of the cache and how often the
-        table should normally be refreshed.
+        information about the initial cache size and how often the table
+        should normally be refreshed.
       </para>
 
       <para>
-        An alternative to implementing an application cache is to use
-        the MySQL query cache. By enabling the query cache, the server
-        handles the details of determining whether a query result can be
-        reused. This simplifies your application. See
+        An attractive alternative to implementing an application cache
+        is to use the MySQL query cache. By enabling the query cache,
+        the server handles the details of determining whether a query
+        result can be reused. This simplifies your application. See
         <xref linkend="query-cache"/>.
       </para>
 
@@ -349,10 +330,10 @@
 
       <para>
         The volume of data was quite huge (about seven million summary
-        transactions per month), and we had data for 4-10 years that we
-        needed to present to the users. We got weekly requests from our
-        customers, who wanted instant access to new reports from this
-        data.
+        transactions per month), and we had data for 4&minus;10 years
+        that we needed to present to the users. We got weekly requests
+        from our customers, who wanted instant access to new reports
+        from this data.
       </para>
 
       <para>
@@ -412,17 +393,11 @@
       </indexterm>
 
       <para>
-        This section should contain a technical description of the MySQL
-        benchmark suite (as well as <command>crash-me</command>), but
-        that description has not yet been written. However, you can get
-        a good idea for how the benchmarks work by looking at the code
-        and results in the <filename>sql-bench</filename> directory in
-        any MySQL source distribution.
-      </para>
-
-      <para>
         This benchmark suite is meant to tell any user what operations a
-        given SQL implementation performs well or poorly.
+        given SQL implementation performs well or poorly. You can get a
+        good idea for how the benchmarks work by looking at the code and
+        results in the <filename>sql-bench</filename> directory in any
+        MySQL source distribution.
       </para>
 
       <para>
@@ -443,8 +418,8 @@
             The benchmark suite is provided with MySQL source
             distributions. You can either download a released
             distribution from <ulink url="&base-url-downloads;"/>, or
-            use the current development source tree (see
-            <xref linkend="installing-source-tree"/>).
+            use the current development source tree. (See
+            <xref linkend="installing-source-tree"/>.)
           </para>
         </listitem>
 
@@ -466,9 +441,10 @@
       <para>
         After you obtain a MySQL source distribution, you can find the
         benchmark suite located in its <filename>sql-bench</filename>
-        directory. To run the benchmark tests, build MySQL, then change
-        location into the <filename>sql-bench</filename> directory and
-        execute the <literal>run-all-tests</literal> script:
+        directory. To run the benchmark tests, build MySQL, and then
+        change location into the <filename>sql-bench</filename>
+        directory and execute the <literal>run-all-tests</literal>
+        script:
       </para>
 
 <programlisting>
@@ -477,9 +453,9 @@
 </programlisting>
 
       <para>
-        <replaceable>server_name</replaceable> is one of the supported
-        servers. To get a list of all options and supported servers,
-        invoke this command:
+        <replaceable>server_name</replaceable> should be the name of one
+        of the supported servers. To get a list of all options and
+        supported servers, invoke this command:
       </para>
 
 <programlisting>
@@ -494,8 +470,9 @@
         The <command>crash-me</command> script also is located in the
         <filename>sql-bench</filename> directory.
         <command>crash-me</command> tries to determine what features a
-        database supports and what its capabilities and limitations are
-        by actually running queries. For example, it determines:
+        database system supports and what its capabilities and
+        limitations are by actually running queries. For example, it
+        determines:
       </para>
 
       <itemizedlist>
@@ -778,12 +755,12 @@
         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
-        finds a matching row in the second table, then in 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 found for which there are more matching rows. The
-        next row is read from this table and the process continues with
-        the next table.
+        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
+        found for which there are more matching rows. The next row is
+        read from this table and the process continues with the next
+        table.
       </para>
 
       <para>
@@ -3926,11 +3903,11 @@
         before the loop and is checked after the loop. The flag is
         turned on when for the current row from the outer table a match
         from the table representing the inner operand is found. If at
-        the end of the loop cycle the flag is still off, then no match
-        has been found for the current row of the outer table. In this
-        case, the row is complemented by <literal>NULL</literal> values
-        for the columns of the inner tables. The result row is passed to
-        the final check for the output or into the next nested loop, but
+        the end of the loop cycle the flag is still off, no match has
+        been found for the current row of the outer table. In this case,
+        the row is complemented by <literal>NULL</literal> values for
+        the columns of the inner tables. The result row is passed to the
+        final check for the output or into the next nested loop, but
         only if the row satisfies the join condition of all embedded
         outer joins.
       </para>
@@ -4757,7 +4734,7 @@
               The <literal>GROUP BY</literal> includes the first
               consecutive parts of the index (if instead of
               <literal>GROUP BY</literal>, the query has a
-              <literal>DISTINCT</literal> clause, then all distinct
+              <literal>DISTINCT</literal> clause, all distinct
               attributes refer to the beginning of the index).
             </para>
           </listitem>
@@ -6007,8 +5984,8 @@
 
       <para>
         When a lock is released, the lock is made available to the
-        threads in the write lock queue, then to the threads in the read
-        lock queue.
+        threads in the write lock queue, and then to the threads in the
+        read lock queue.
       </para>
 
       <para>
@@ -6958,7 +6935,7 @@
         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, then this is at least 100 times faster than reading
+        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.
@@ -7619,8 +7596,8 @@
         <para>
           One reason the use of three key caches is beneficial is that
           access to one key cache structure does not block access to the
-          others. Queries that access tables assigned to one cache do
-          not compete with queries that access tables assigned to
+          others. Statements that access tables assigned to one cache do
+          not compete with statements that access tables assigned to
           another cache. Performance gains occur for other reasons as
           well:
         </para>
@@ -7791,10 +7768,10 @@
         <para>
           If there are enough blocks in a key cache to hold blocks of an
           entire index, or at least the blocks corresponding to its
-          non-leaf nodes, then it makes sense to preload the key cache
-          with index blocks before starting to use it. Preloading allows
-          you to put the table index blocks into a key cache buffer in
-          the most efficient way: by reading the index blocks from disk
+          non-leaf nodes, it makes sense to preload the key cache with
+          index blocks before starting to use it. Preloading allows you
+          to put the table index blocks into a key cache buffer in the
+          most efficient way: by reading the index blocks from disk
           sequentially.
         </para>
 
@@ -9028,10 +9005,10 @@
         possible query evaluation plans. For join queries, the number of
         possible plans investigated by the MySQL optimizer grows
         exponentially with the number of tables referenced in a query.
-        For small numbers of tables (typically less than 7-10) this is
-        not a problem. However, when bigger queries are submitted, the
-        time spent in query optimization may easily become the major
-        bottleneck in the server's performance.
+        For small numbers of tables (typically less than 7&minus;10)
+        this is not a problem. However, when bigger queries are
+        submitted, the time spent in query optimization may easily
+        become the major bottleneck in the server's performance.
       </para>
 
       <para>
@@ -9061,7 +9038,7 @@
             compilation times. That is why this option is on
             (<literal>optimizer_prune_level</literal>=1) by default.
             However, if you believe that the optimizer missed a better
-            query plan, then this option can be switched off
+            query plan, this option can be switched off
             (<literal>optimizer_prune_level</literal>=0) with the risk
             that query compilation may take much longer. Notice that
             even with the use of this heuristic, the optimizer still
@@ -9147,7 +9124,7 @@
 
       <para>
         By using a better compiler and compilation options, you can
-        obtain a 10-30% speed increase in applications. This is
+        obtain a 10&minus;30% speed increase in applications. This is
         particularly important if you compile the MySQL server yourself.
       </para>
 
@@ -9216,8 +9193,8 @@
         <listitem>
           <para>
             For TCP/IP connections from a client to a server, connecting
-            to a remote server on another host is 8-11% slower than
-            connecting to a server on the same host, even for
+            to a remote server on another host is 8&minus;11% slower
+            than connecting to a server on the same host, even for
             connections over 100Mb/s Ethernet.
           </para>
         </listitem>
@@ -9270,9 +9247,9 @@
 
         <listitem>
           <para>
-            On Solaris 2.5.1, MIT-pthreads is 8-12% slower than Solaris
-            native threads on a single processor. With greater loads or
-            more CPUs, the difference should be larger.
+            On Solaris 2.5.1, MIT-pthreads is 8&minus;12% slower than
+            Solaris native threads on a single processor. With greater
+            loads or more CPUs, the difference should be larger.
           </para>
         </listitem>
 
@@ -9281,7 +9258,7 @@
             Compiling on Linux-x86 using <command>gcc</command> without
             frame pointers (<option>-fomit-frame-pointer</option> or
             <option>-fomit-frame-pointer -ffixed-ebp</option>) makes
-            <command>mysqld</command> 1-4% faster.
+            <command>mysqld</command> 1&minus;4% faster.
           </para>
         </listitem>
 

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-15 04:58:22 UTC (rev 839)
+++ trunk/refman-common/titles.en.ent	2006-01-15 04:58:40 UTC (rev 840)
@@ -317,7 +317,7 @@
 <!ENTITY title-differences-from-ansi "MySQL Differences from Standard SQL">
 <!ENTITY title-disaster-prevention "Backup and Recovery">
 <!ENTITY title-disk-issues "Disk Issues">
-<!ENTITY title-distinct-optimization "How MySQL Optimizes <literal>DISTINCT</literal>">
+<!ENTITY title-distinct-optimization "<literal>DISTINCT</literal> Optimization">
 <!ENTITY title-dns "How MySQL Uses DNS">
 <!ENTITY title-do "<literal>DO</literal> Syntax">
 <!ENTITY title-doctoexcel "How to Retrieve Data from MySQL into MS-Word/Excel Documents?">
@@ -439,7 +439,7 @@
 <!ENTITY title-group-by-functions-and-modifiers "Functions and Modifiers for Use with <literal>GROUP BY</literal> Clauses">
 <!ENTITY title-group-by-hidden-fields "<literal>GROUP BY</literal> with Hidden Fields">
 <!ENTITY title-group-by-modifiers "<literal>GROUP BY</literal> Modifiers">
-<!ENTITY title-group-by-optimization "How MySQL Optimizes <literal>GROUP BY</literal>">
+<!ENTITY title-group-by-optimization "<literal>GROUP BY</literal> Optimization">
 <!ENTITY title-handler "<literal>HANDLER</literal> Syntax">
 <!ENTITY title-hexadecimal-values "Hexadecimal Values">
 <!ENTITY title-history "History of MySQL">
@@ -453,10 +453,10 @@
 <!ENTITY title-ignoring-user "<literal>Ignoring user</literal>">
 <!ENTITY title-implicit-commit "Statements That Cause an Implicit Commit">
 <!ENTITY title-import-of-data "How to Import or Link MySQL Database Tables to Access?">
-<!ENTITY title-index-merge-intersection "Index Merge Intersection Access Algorithm">
+<!ENTITY title-index-merge-intersection "The Index Merge Intersection Access Algorithm">
 <!ENTITY title-index-merge-optimization "Index Merge Optimization">
-<!ENTITY title-index-merge-sort-union "Index Merge Sort-Union Access Algorithm">
-<!ENTITY title-index-merge-union "Index Merge Union Access Algorithm">
+<!ENTITY title-index-merge-sort-union "The Index Merge Sort-Union Access Algorithm">
+<!ENTITY title-index-merge-union "The Index Merge Union Access Algorithm">
 <!ENTITY title-index-preloading "Index Preloading">
 <!ENTITY title-indexes "Column Indexes">
 <!ENTITY title-information-functions "Information Functions">
@@ -577,7 +577,7 @@
 <!ENTITY title-introduction-to-odbc "Introduction to ODBC">
 <!ENTITY title-invoking-programs "Invoking MySQL Programs">
 <!ENTITY title-irc "MySQL Community Support on Internet Relay Chat (IRC)">
-<!ENTITY title-is-null-optimization "How MySQL Optimizes <literal>IS NULL</literal>">
+<!ENTITY title-is-null-optimization "<literal>IS NULL</literal> Optimization">
 <!ENTITY title-isam-storage-engine "The <literal>ISAM</literal> Storage Engine">
 <!ENTITY title-isamchk-for-manpage "ISAM table-maintenance utility">
 <!ENTITY title-isamlog-for-manpage "display contents of ISAM log file">
@@ -593,7 +593,7 @@
 <!ENTITY title-language-structure "Language Structure">
 <!ENTITY title-languages "Setting the Error Message Language">
 <!ENTITY title-leave-statement "<literal>LEAVE</literal> Statement">
-<!ENTITY title-left-join-optimization "How MySQL Optimizes <literal>LEFT JOIN</literal> and <literal>RIGHT JOIN</literal>">
+<!ENTITY title-left-join-optimization "<literal>LEFT JOIN</literal> and <literal>RIGHT JOIN</literal> Optimization">
 <!ENTITY title-legal-names "Database, Table, Index, Column, and Alias Names">
 <!ENTITY title-libmysqld "libmysqld, the Embedded MySQL Server Library">
 <!ENTITY title-libmysqld-compiling "Compiling Programs with <literal>libmysqld</literal>">
@@ -603,7 +603,7 @@
 <!ENTITY title-libmysqld-overview "Overview of the Embedded MySQL Server Library">
 <!ENTITY title-libmysqld-restrictions "Restrictions when using the Embedded MySQL Server">
 <!ENTITY title-libmysqld-todo "Things left to do in Embedded Server (TODO)">
-<!ENTITY title-limit-optimization "How MySQL Optimizes <literal>LIMIT</literal>">
+<!ENTITY title-limit-optimization "<literal>LIMIT</literal> Optimization">
 <!ENTITY title-limits "Limits in MySQL">
 <!ENTITY title-linestring-property-functions "<literal>LineString</literal> Functions">
 <!ENTITY title-link-errors "Problems Linking to the MySQL Client Library">
@@ -1016,7 +1016,7 @@
 <!ENTITY title-ndbcluster "MySQL Cluster">
 <!ENTITY title-ndbd-command-options "Command Options for <command>ndbd</command>">
 <!ENTITY title-ndbd-process "<command>ndbd</command>, the Storage Engine Node Process">
-<!ENTITY title-nested-joins "How MySQL Optimizes Nested Joins">
+<!ENTITY title-nested-joins "Nested Join Optimization">
 <!ENTITY title-netbsd "NetBSD Notes">
 <!ENTITY title-netware-installation "Installing MySQL on NetWare">
 <!ENTITY title-new-mysqld-command-options "MySQL Cluster-Related Command Options for <command>mysqld</command>">
@@ -1291,7 +1291,7 @@
 <!ENTITY title-optimizing-subqueries "Optimizing Subqueries">
 <!ENTITY title-optimizing-the-server "Optimizing the MySQL Server">
 <!ENTITY title-option-files "Using Option Files">
-<!ENTITY title-order-by-optimization "How MySQL Optimizes <literal>ORDER BY</literal>">
+<!ENTITY title-order-by-optimization "<literal>ORDER BY</literal> Optimization">
 <!ENTITY title-os-2 "OS/2 Notes">
 <!ENTITY title-other-administrative-sql "Other Administrative Statements">
 <!ENTITY title-other-functions "Other Functions">
@@ -1299,7 +1299,7 @@
 <!ENTITY title-other-unix-notes "Other Unix Notes">
 <!ENTITY title-other-vendor-data-types "Using Data Types from Other Database Engines">
 <!ENTITY title-out-of-memory "<literal>Out of memory</literal>">
-<!ENTITY title-outer-join-simplification "How MySQL Simplifies Outer Joins">
+<!ENTITY title-outer-join-simplification "Outer Join Simplification">
 <!ENTITY title-pack-isam-for-manpage "generate compressed, read-only <literal>ISAM</literal> tables">
 <!ENTITY title-packages "Packages that support MySQL">
 <!ENTITY title-packet-too-large "<literal>Packet too large</literal>">
@@ -1399,8 +1399,8 @@
 <!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">
-<!ENTITY title-range-access-multi-part "Range Access Method for Multiple-Part Indexes">
-<!ENTITY title-range-access-single-part "Range Access Method for Single-Part Indexes">
+<!ENTITY title-range-access-multi-part "The Range Access Method for Multiple-Part Indexes">
+<!ENTITY title-range-access-single-part "The Range Access Method for Single-Part Indexes">
 <!ENTITY title-range-optimization "Range Optimization">
 <!ENTITY title-rdo-rs-addnew-and-rs-update "RDO: <literal>rs.addNew</literal> and <literal>rs.update</literal>">
 <!ENTITY title-refman-4-1 "MySQL 4.1 Reference Manual"><!-- Title of Manual 4.1 edition  -->
@@ -1678,7 +1678,7 @@
 <!ENTITY title-what-is-crashing "How to Determine What Is Causing a Problem">
 <!ENTITY title-what-is-mysql-ab "Overview of MySQL AB">
 <!ENTITY title-what-privileges "What the Privilege System Does">
-<!ENTITY title-where-optimizations "How MySQL Optimizes <literal>WHERE</literal> Clauses">
+<!ENTITY title-where-optimizations "<literal>WHERE</literal> Clause Optimization">
 <!ENTITY title-where-to-get-myodbc "Where to Get MyODBC">
 <!ENTITY title-which-os "Operating Systems Supported by MySQL">
 <!ENTITY title-which-version "Choosing Which MySQL Distribution to Install">

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