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

Log:
 r6235@frost:  paul | 2006-01-15 09:05:25 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/optimization.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.1/optimization.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6219
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6235
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 15:29:00 UTC (rev 844)
+++ trunk/refman-4.1/optimization.xml	2006-01-16 02:40:52 UTC (rev 845)
@@ -536,18 +536,20 @@
         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 easily 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.
+        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.
       </para>
 
       <para>
-        For an example of a portable benchmark program, look at the
-        MySQL benchmark suite. See <xref linkend="mysql-benchmarks"/>.
-        You can take any program from this suite and modify it for your
-        own needs. By doing this, you can try different solutions to
-        your problem and test which really is fastest for you.
+        For examples of portable benchmark programs, look at those in
+        the MySQL benchmark suite. See
+        <xref linkend="mysql-benchmarks"/>. You can take any program
+        from this suite and modify it for your own needs. By doing this,
+        you can try different solutions to your problem and test which
+        really is fastest for you.
       </para>
 
       <para>
@@ -564,17 +566,17 @@
         turn out to be due to issues of basic database design (for
         example, table scans are not good under high load) or problems
         with the operating system or libraries. Most of the time, these
-        problems would be much easier to fix if the systems were not in
-        production.
+        problems would be much easier to fix if the systems were not
+        already in production.
       </para>
 
       <para>
         To avoid problems like this, you should put some effort into
         benchmarking your whole application under the worst possible
-        load. You can use Super Smack for this. It is available at
+        load. You can use Super Smack, available at
         <ulink url="http://jeremy.zawodny.com/mysql/super-smack/"/>. As
-        the name suggests, 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 if you
+        ask it, so make sure to use it only on your development systems.
       </para>
 
     </section>
@@ -602,29 +604,28 @@
 
     <para>
       First, one factor affects all statements: The more complex your
-      permissions setup, the more overhead you have.
-    </para>
-
-    <para>
-      Using simpler permissions when you issue <literal>GRANT</literal>
-      statements enables MySQL to reduce permission-checking overhead
-      when clients execute statements. For example, if you do not grant
-      any table-level or column-level privileges, the server need not
-      ever check the contents of the <literal>tables_priv</literal> and
+      permissions setup, the more overhead you have. Using simpler
+      permissions when you issue <literal>GRANT</literal> statements
+      enables MySQL to reduce permission-checking overhead when clients
+      execute statements. For example, if you do not grant any
+      table-level or column-level privileges, the server need not ever
+      check the contents of the <literal>tables_priv</literal> and
       <literal>columns_priv</literal> tables. Similarly, if you place no
       resource limits on any accounts, the server does not have to
-      perform resource counting. If you have a very high query volume,
-      it may be worth the time to use a simplified grant structure to
-      reduce permission-checking overhead.
+      perform resource counting. If you have a very high
+      statement-processing load, it may be worth the time to use a
+      simplified grant structure to reduce permission-checking overhead.
     </para>
 
     <para>
       If your problem is with a specific MySQL expression or function,
-      you can use the <literal>BENCHMARK()</literal> function from the
-      <command>mysql</command> client program to perform a timing test.
-      Its syntax is
+      you can perform a timing test by invoking the
+      <literal>BENCHMARK()</literal> function using the
+      <command>mysql</command> client program. Its syntax is
       <literal>BENCHMARK(<replaceable>loop_count</replaceable>,<replaceable>expression</replaceable>)</literal>.
-      For example:
+      The return value is always zero, but <command>mysql</command>
+      prints a line displaying approximately how long the statement took
+      to execute. For example:
     </para>
 
 <programlisting>
@@ -646,7 +647,8 @@
     <para>
       All MySQL functions should be highly optimized, but there may be
       some exceptions. <literal>BENCHMARK()</literal> is an excellent
-      tool for finding out if this is a problem with your query.
+      tool for finding out if some function is a problem for your
+      queries.
     </para>
 
     <section id="explain">

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-15 15:29:00 UTC (rev 844)
+++ trunk/refman-5.0/optimization.xml	2006-01-16 02:40:52 UTC (rev 845)
@@ -536,18 +536,20 @@
         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 easily 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.
+        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.
       </para>
 
       <para>
-        For an example of a portable benchmark program, look at the
-        MySQL benchmark suite. See <xref linkend="mysql-benchmarks"/>.
-        You can take any program from this suite and modify it for your
-        own needs. By doing this, you can try different solutions to
-        your problem and test which really is fastest for you.
+        For examples of portable benchmark programs, look at those in
+        the MySQL benchmark suite. See
+        <xref linkend="mysql-benchmarks"/>. You can take any program
+        from this suite and modify it for your own needs. By doing this,
+        you can try different solutions to your problem and test which
+        really is fastest for you.
       </para>
 
       <para>
@@ -564,17 +566,17 @@
         turn out to be due to issues of basic database design (for
         example, table scans are not good under high load) or problems
         with the operating system or libraries. Most of the time, these
-        problems would be much easier to fix if the systems were not in
-        production.
+        problems would be much easier to fix if the systems were not
+        already in production.
       </para>
 
       <para>
         To avoid problems like this, you should put some effort into
         benchmarking your whole application under the worst possible
-        load. You can use Super Smack for this. It is available at
+        load. You can use Super Smack, available at
         <ulink url="http://jeremy.zawodny.com/mysql/super-smack/"/>. As
-        the name suggests, 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 if you
+        ask it, so make sure to use it only on your development systems.
       </para>
 
     </section>
@@ -602,29 +604,28 @@
 
     <para>
       First, one factor affects all statements: The more complex your
-      permissions setup, the more overhead you have.
-    </para>
-
-    <para>
-      Using simpler permissions when you issue <literal>GRANT</literal>
-      statements enables MySQL to reduce permission-checking overhead
-      when clients execute statements. For example, if you do not grant
-      any table-level or column-level privileges, the server need not
-      ever check the contents of the <literal>tables_priv</literal> and
+      permissions setup, the more overhead you have. Using simpler
+      permissions when you issue <literal>GRANT</literal> statements
+      enables MySQL to reduce permission-checking overhead when clients
+      execute statements. For example, if you do not grant any
+      table-level or column-level privileges, the server need not ever
+      check the contents of the <literal>tables_priv</literal> and
       <literal>columns_priv</literal> tables. Similarly, if you place no
       resource limits on any accounts, the server does not have to
-      perform resource counting. If you have a very high query volume,
-      it may be worth the time to use a simplified grant structure to
-      reduce permission-checking overhead.
+      perform resource counting. If you have a very high
+      statement-processing load, it may be worth the time to use a
+      simplified grant structure to reduce permission-checking overhead.
     </para>
 
     <para>
       If your problem is with a specific MySQL expression or function,
-      you can use the <literal>BENCHMARK()</literal> function from the
-      <command>mysql</command> client program to perform a timing test.
-      Its syntax is
+      you can perform a timing test by invoking the
+      <literal>BENCHMARK()</literal> function using the
+      <command>mysql</command> client program. Its syntax is
       <literal>BENCHMARK(<replaceable>loop_count</replaceable>,<replaceable>expression</replaceable>)</literal>.
-      For example:
+      The return value is always zero, but <command>mysql</command>
+      prints a line displaying approximately how long the statement took
+      to execute. For example:
     </para>
 
 <programlisting>
@@ -646,7 +647,8 @@
     <para>
       All MySQL functions should be highly optimized, but there may be
       some exceptions. <literal>BENCHMARK()</literal> is an excellent
-      tool for finding out if this is a problem with your query.
+      tool for finding out if some function is a problem for your
+      queries.
     </para>
 
     <section id="explain">

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-15 15:29:00 UTC (rev 844)
+++ trunk/refman-5.1/optimization.xml	2006-01-16 02:40:52 UTC (rev 845)
@@ -536,18 +536,20 @@
         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 easily 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.
+        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.
       </para>
 
       <para>
-        For an example of a portable benchmark program, look at the
-        MySQL benchmark suite. See <xref linkend="mysql-benchmarks"/>.
-        You can take any program from this suite and modify it for your
-        own needs. By doing this, you can try different solutions to
-        your problem and test which really is fastest for you.
+        For examples of portable benchmark programs, look at those in
+        the MySQL benchmark suite. See
+        <xref linkend="mysql-benchmarks"/>. You can take any program
+        from this suite and modify it for your own needs. By doing this,
+        you can try different solutions to your problem and test which
+        really is fastest for you.
       </para>
 
       <para>
@@ -564,17 +566,17 @@
         turn out to be due to issues of basic database design (for
         example, table scans are not good under high load) or problems
         with the operating system or libraries. Most of the time, these
-        problems would be much easier to fix if the systems were not in
-        production.
+        problems would be much easier to fix if the systems were not
+        already in production.
       </para>
 
       <para>
         To avoid problems like this, you should put some effort into
         benchmarking your whole application under the worst possible
-        load. You can use Super Smack for this. It is available at
+        load. You can use Super Smack, available at
         <ulink url="http://jeremy.zawodny.com/mysql/super-smack/"/>. As
-        the name suggests, 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 if you
+        ask it, so make sure to use it only on your development systems.
       </para>
 
     </section>
@@ -602,29 +604,28 @@
 
     <para>
       First, one factor affects all statements: The more complex your
-      permissions setup, the more overhead you have.
-    </para>
-
-    <para>
-      Using simpler permissions when you issue <literal>GRANT</literal>
-      statements enables MySQL to reduce permission-checking overhead
-      when clients execute statements. For example, if you do not grant
-      any table-level or column-level privileges, the server need not
-      ever check the contents of the <literal>tables_priv</literal> and
+      permissions setup, the more overhead you have. Using simpler
+      permissions when you issue <literal>GRANT</literal> statements
+      enables MySQL to reduce permission-checking overhead when clients
+      execute statements. For example, if you do not grant any
+      table-level or column-level privileges, the server need not ever
+      check the contents of the <literal>tables_priv</literal> and
       <literal>columns_priv</literal> tables. Similarly, if you place no
       resource limits on any accounts, the server does not have to
-      perform resource counting. If you have a very high query volume,
-      it may be worth the time to use a simplified grant structure to
-      reduce permission-checking overhead.
+      perform resource counting. If you have a very high
+      statement-processing load, it may be worth the time to use a
+      simplified grant structure to reduce permission-checking overhead.
     </para>
 
     <para>
       If your problem is with a specific MySQL expression or function,
-      you can use the <literal>BENCHMARK()</literal> function from the
-      <command>mysql</command> client program to perform a timing test.
-      Its syntax is
+      you can perform a timing test by invoking the
+      <literal>BENCHMARK()</literal> function using the
+      <command>mysql</command> client program. Its syntax is
       <literal>BENCHMARK(<replaceable>loop_count</replaceable>,<replaceable>expression</replaceable>)</literal>.
-      For example:
+      The return value is always zero, but <command>mysql</command>
+      prints a line displaying approximately how long the statement took
+      to execute. For example:
     </para>
 
 <programlisting>
@@ -646,7 +647,8 @@
     <para>
       All MySQL functions should be highly optimized, but there may be
       some exceptions. <literal>BENCHMARK()</literal> is an excellent
-      tool for finding out if this is a problem with your query.
+      tool for finding out if some function is a problem for your
+      queries.
     </para>
 
     <section id="explain">

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