List:Commits« Previous MessageNext Message »
From:paul Date:January 17 2006 5:13pm
Subject:svn commit - mysqldoc@docsrva: r872 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-17 18:13:14 +0100 (Tue, 17 Jan 2006)
New Revision: 872

Log:
 r6306@frost:  paul | 2006-01-17 11:09:03 -0600
 Cleanup revisions.


Modified:
   trunk/
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/installing.xml
   trunk/refman-4.1/language-structure.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/installing.xml
   trunk/refman-5.0/language-structure.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/installing.xml
   trunk/refman-5.1/language-structure.xml
   trunk/refman-5.1/ndbcluster.xml


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

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-4.1/innodb.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -1560,7 +1560,7 @@
         <para>
           A typical setting for a problematic workload might be 1
           million, assuming that our transactions are small, only 100
-          bytes in size, and we can allow 100 MB of unpurged rows in our
+          bytes in size, and we can allow 100MB of unpurged rows in our
           tables.
         </para>
       </listitem>
@@ -5409,8 +5409,8 @@
       batches at about the same rate in the table, it is possible that
       the purge thread starts to lag behind, and the table grows bigger
       and bigger, making everything disk-bound and very slow. Even if
-      the table would carry just 10 MB of useful data, it may grow to
-      occupy 10 GB with all the dead rows. In such a case, it would be
+      the table would carry just 10MB of useful data, it may grow to
+      occupy 10GB with all the dead rows. In such a case, it would be
       good to throttle new row operations, and allocate more resources
       for the purge thread. Starting with MySQL 4.0.22 and 4.1.6, the
       <literal>innodb_max_purge_lag</literal> system variable exists for
@@ -5850,7 +5850,7 @@
       <para>
         (In the preceding query, we are <quote>fooling</quote> the SQL
         optimizer into scanning the clustered index, rather than a
-        secondary index.) Most disks can read 10 to 50 MB/s, which can
+        secondary index.) Most disks can read 10 to 50MB/s, which can
         be used to estimate how fast a table scan should run.
       </para>
 

Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-4.1/installing.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -9313,7 +9313,7 @@
 
         <listitem>
           <para>
-            Between 3 and 5 GB disk space.
+            Between 3GB and 5GB disk space.
           </para>
         </listitem>
 
@@ -17184,7 +17184,7 @@
 
           <listitem>
             <para>
-              Increased memory support up to 64 GB
+              Increased memory support up to 64GB
             </para>
           </listitem>
 

Modified: trunk/refman-4.1/language-structure.xml
===================================================================
--- trunk/refman-4.1/language-structure.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-4.1/language-structure.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -1340,10 +1340,13 @@
       other characters if you quote it as a string or identifier (for
       example, <literal>@'my-var'</literal>,
       <literal>@"my-var"</literal>, or <literal>@`my-var`</literal>).
-      User variable names are case sensitive prior to MySQL 5.0.
     </para>
 
     <para>
+      Note: User variable names are case sensitive prior to MySQL 5.0.
+    </para>
+
+    <para>
       One way to set a user variable is by issuing a
       <literal>SET</literal> statement:
     </para>

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -669,7 +669,7 @@
           For our sample data, we will use the <literal>world</literal>
           database which is available for download from the MySQL AB Web
           site. As this database takes up a relatively small amount of
-          space, we assume that each machine has 256 MB RAM, which
+          space, we assume that each machine has 256MB RAM, which
           should be sufficient for running the operating system, host
           NDB process, and (for the data nodes) for storing the
           database.
@@ -3124,9 +3124,9 @@
             </para>
 
             <para>
-              Thus, for one million records, we need 58 MB for index
+              Thus, for one million records, we need 58MB for index
               memory to handle the hash indexes for the primary key and
-              the unique constraint. We also need 64 MB for the records
+              the unique constraint. We also need 64MB for the records
               of the base table and the unique index table, plus the two
               ordered index tables.
             </para>
@@ -5372,7 +5372,7 @@
             <para>
               Each SCI transporter has a shared memory segment used for
               communication between the two nodes. Setting the size of
-              this segment to the default value of 1 MB should be
+              this segment to the default value of 1MB should be
               sufficient for most applications. Using a smaller value
               can lead to problems when performing many parallel
               inserts; if the shared buffer is too small, this can also
@@ -5388,10 +5388,10 @@
             <para>
               A small buffer in front of the SCI media stores messages
               before transmitting them over the SCI network. By default
-              this is set to 8kB. Our benchmarks show that performance
-              is best at 64 kB but 16kB reaches within a few percent of
+              this is set to 8KB. Our benchmarks show that performance
+              is best at 64KB but 16KB reaches within a few percent of
               this, and there was little if any advantage to increasing
-              it beyond 8kB.
+              it beyond 8KB.
             </para>
           </listitem>
 
@@ -8859,8 +8859,8 @@
         transporter using TCP/IP sockets and a similar setup using SCI
         sockets. The figures reported below are for small accesses of 20
         records per access. The difference between serial and batched
-        access decreases by a factor of 3 to 4 when using 2 kB records
-        instead. SCI Sockets were not tested with 2 kB records. Tests
+        access decreases by a factor of 3 to 4 when using 2KB records
+        instead. SCI Sockets were not tested with 2KB records. Tests
         were performed on a cluster with 2 data nodes running on 2
         dual-CPU machines equipped with AMD MP1900+ processors.
       </para>
@@ -10897,7 +10897,7 @@
           database times the number of replicas, divided by the number
           of data nodes. Thus, if the database takes up 1 gigabyte of
           memory, and you wish to set up the cluster with 4 replicas and
-          8 data nodes, a minimum of 500 MB memory will be required per
+          8 data nodes, a minimum of 500MB memory will be required per
           node. Note that this is in addition to any requirements for
           the operating system and any other applications that might be
           running on the host.

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.0/database-administration.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -3418,7 +3418,7 @@
 
             <para>
               Some hardware/operating system architectures support
-              memory pages greater than the default (usually 4 KB). The
+              memory pages greater than the default (usually 4KB). The
               actual implementation of this support depends on the
               underlying hardware and OS. Applications that perform a
               lot of memory access may obtain performance improvements

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.0/innodb.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -1575,7 +1575,7 @@
         <para>
           A typical setting for a problematic workload might be 1
           million, assuming that our transactions are small, only 100
-          bytes in size, and we can allow 100 MB of unpurged rows in our
+          bytes in size, and we can allow 100MB of unpurged rows in our
           tables.
         </para>
       </listitem>
@@ -5349,8 +5349,8 @@
       batches at about the same rate in the table, it is possible that
       the purge thread starts to lag behind, and the table grows bigger
       and bigger, making everything disk-bound and very slow. Even if
-      the table carries just 10 MB of useful data, it may grow to occupy
-      10 GB with all the <quote>dead</quote> rows. In such a case, it
+      the table carries just 10MB of useful data, it may grow to occupy
+      10GB with all the <quote>dead</quote> rows. In such a case, it
       would be good to throttle new row operations, and allocate more
       resources to the purge thread. The
       <literal>innodb_max_purge_lag</literal> system variable exists for
@@ -5788,7 +5788,7 @@
       <para>
         (In the preceding query, we are <quote>fooling</quote> the SQL
         optimizer into scanning the clustered index, rather than a
-        secondary index.) Most disks can read 10 to 50 MB/s, which can
+        secondary index.) Most disks can read 10 to 50MB/s, which can
         be used to estimate how fast a table scan should run.
       </para>
 

Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.0/installing.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -9207,7 +9207,7 @@
 
         <listitem>
           <para>
-            Between 3 and 5 GB disk space.
+            Between 3GB and 5GB disk space.
           </para>
         </listitem>
 
@@ -16353,7 +16353,7 @@
 
           <listitem>
             <para>
-              Increased memory support up to 64 GB
+              Increased memory support up to 64GB
             </para>
           </listitem>
 

Modified: trunk/refman-5.0/language-structure.xml
===================================================================
--- trunk/refman-5.0/language-structure.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.0/language-structure.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -1319,10 +1319,14 @@
       other characters if you quote it as a string or identifier (for
       example, <literal>@'my-var'</literal>,
       <literal>@"my-var"</literal>, or <literal>@`my-var`</literal>).
-      User variable names are not case sensitive.
     </para>
 
     <para>
+      Note: User variable names are case sensitive before MySQL 5.0 and
+      not case sensitive in MySQL 5.0 and up.
+    </para>
+
+    <para>
       One way to set a user-defined variable is by issuing a
       <literal>SET</literal> statement:
     </para>

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -668,7 +668,7 @@
           For our sample data, we will use the <literal>world</literal>
           database which is available for download from the MySQL AB Web
           site. As this database takes up a relatively small amount of
-          space, we assume that each machine has 256 MB RAM, which
+          space, we assume that each machine has 256MB RAM, which
           should be sufficient for running the operating system, host
           NDB process, and (for the data nodes) for storing the
           database.
@@ -3118,9 +3118,9 @@
             </para>
 
             <para>
-              Thus, for one million records, we need 58 MB for index
+              Thus, for one million records, we need 58MB for index
               memory to handle the hash indexes for the primary key and
-              the unique constraint. We also need 64 MB for the records
+              the unique constraint. We also need 64MB for the records
               of the base table and the unique index table, plus the two
               ordered index tables.
             </para>
@@ -5379,7 +5379,7 @@
             <para>
               Each SCI transporter has a shared memory segment used for
               communication between the two nodes. Setting the size of
-              this segment to the default value of 1 MB should be
+              this segment to the default value of 1MB should be
               sufficient for most applications. Using a smaller value
               can lead to problems when performing many parallel
               inserts; if the shared buffer is too small, this can also
@@ -5395,10 +5395,10 @@
             <para>
               A small buffer in front of the SCI media stores messages
               before transmitting them over the SCI network. By default
-              this is set to 8kB. Our benchmarks show that performance
-              is best at 64 kB but 16kB reaches within a few percent of
+              this is set to 8KB. Our benchmarks show that performance
+              is best at 64KB but 16KB reaches within a few percent of
               this, and there was little if any advantage to increasing
-              it beyond 8kB.
+              it beyond 8KB.
             </para>
           </listitem>
 
@@ -8830,8 +8830,8 @@
         transporter using TCP/IP sockets and a similar setup using SCI
         sockets. The figures reported below are for small accesses of 20
         records per access. The difference between serial and batched
-        access decreases by a factor of 3 to 4 when using 2 kB records
-        instead. SCI Sockets were not tested with 2 kB records. Tests
+        access decreases by a factor of 3 to 4 when using 2KB records
+        instead. SCI Sockets were not tested with 2KB records. Tests
         were performed on a cluster with 2 data nodes running on 2
         dual-CPU machines equipped with AMD MP1900+ processors.
       </para>
@@ -11180,7 +11180,7 @@
           database times the number of replicas, divided by the number
           of data nodes. Thus, if the database takes up 1 gigabyte of
           memory, and you wish to set up the cluster with 4 replicas and
-          8 data nodes, a minimum of 500 MB memory will be required per
+          8 data nodes, a minimum of 500MB memory will be required per
           node. Note that this is in addition to any requirements for
           the operating system and any other applications that might be
           running on the host.

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.1/database-administration.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -3399,7 +3399,7 @@
 
             <para>
               Some hardware/operating system architectures support
-              memory pages greater than the default (usually 4 KB). The
+              memory pages greater than the default (usually 4KB). The
               actual implementation of this support depends on the
               underlying hardware and OS. Applications that perform a
               lot of memory access may obtain performance improvements

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.1/innodb.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -1568,7 +1568,7 @@
         <para>
           A typical setting for a problematic workload might be 1
           million, assuming that our transactions are small, only 100
-          bytes in size, and we can allow 100 MB of unpurged rows in our
+          bytes in size, and we can allow 100MB of unpurged rows in our
           tables.
         </para>
       </listitem>
@@ -5309,8 +5309,8 @@
       batches at about the same rate in the table, it is possible that
       the purge thread starts to lag behind, and the table grows bigger
       and bigger, making everything disk-bound and very slow. Even if
-      the table carries just 10 MB of useful data, it may grow to occupy
-      10 GB with all the <quote>dead</quote> rows. In such a case, it
+      the table carries just 10MB of useful data, it may grow to occupy
+      10GB with all the <quote>dead</quote> rows. In such a case, it
       would be good to throttle new row operations, and allocate more
       resources to the purge thread. The
       <literal>innodb_max_purge_lag</literal> system variable exists for
@@ -5744,7 +5744,7 @@
       <para>
         (In the preceding query, we are <quote>fooling</quote> the SQL
         optimizer into scanning the clustered index, rather than a
-        secondary index.) Most disks can read 10 to 50 MB/s, which can
+        secondary index.) Most disks can read 10 to 50MB/s, which can
         be used to estimate how fast a table scan should run.
       </para>
 

Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.1/installing.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -9209,7 +9209,7 @@
 
         <listitem>
           <para>
-            Between 3 and 5 GB disk space.
+            Between 3GB and 5GB disk space.
           </para>
         </listitem>
 
@@ -15661,7 +15661,7 @@
 
           <listitem>
             <para>
-              Increased memory support up to 64 GB
+              Increased memory support up to 64GB
             </para>
           </listitem>
 

Modified: trunk/refman-5.1/language-structure.xml
===================================================================
--- trunk/refman-5.1/language-structure.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.1/language-structure.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -1319,10 +1319,14 @@
       other characters if you quote it as a string or identifier (for
       example, <literal>@'my-var'</literal>,
       <literal>@"my-var"</literal>, or <literal>@`my-var`</literal>).
-      User variable names are not case sensitive.
     </para>
 
     <para>
+      Note: User variable names are case sensitive before MySQL 5.0 and
+      not case sensitive in MySQL 5.0 and up.
+    </para>
+
+    <para>
       One way to set a user-defined variable is by issuing a
       <literal>SET</literal> statement:
     </para>

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-17 16:53:44 UTC (rev 871)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-17 17:13:14 UTC (rev 872)
@@ -668,7 +668,7 @@
           For our sample data, we will use the <literal>world</literal>
           database which is available for download from the MySQL AB Web
           site. As this database takes up a relatively small amount of
-          space, we assume that each machine has 256 MB RAM, which
+          space, we assume that each machine has 256MB RAM, which
           should be sufficient for running the operating system, host
           NDB process, and (for the data nodes) for storing the
           database.
@@ -3116,9 +3116,9 @@
             </para>
 
             <para>
-              Thus, for one million records, we need 58 MB for index
+              Thus, for one million records, we need 58MB for index
               memory to handle the hash indexes for the primary key and
-              the unique constraint. We also need 64 MB for the records
+              the unique constraint. We also need 64MB for the records
               of the base table and the unique index table, plus the two
               ordered index tables.
             </para>
@@ -5377,7 +5377,7 @@
             <para>
               Each SCI transporter has a shared memory segment used for
               communication between the two nodes. Setting the size of
-              this segment to the default value of 1 MB should be
+              this segment to the default value of 1MB should be
               sufficient for most applications. Using a smaller value
               can lead to problems when performing many parallel
               inserts; if the shared buffer is too small, this can also
@@ -5393,10 +5393,10 @@
             <para>
               A small buffer in front of the SCI media stores messages
               before transmitting them over the SCI network. By default
-              this is set to 8kB. Our benchmarks show that performance
-              is best at 64 kB but 16kB reaches within a few percent of
+              this is set to 8KB. Our benchmarks show that performance
+              is best at 64KB but 16KB reaches within a few percent of
               this, and there was little if any advantage to increasing
-              it beyond 8kB.
+              it beyond 8KB.
             </para>
           </listitem>
 
@@ -10440,8 +10440,8 @@
         transporter using TCP/IP sockets and a similar setup using SCI
         sockets. The figures reported below are for small accesses of 20
         records per access. The difference between serial and batched
-        access decreases by a factor of 3 to 4 when using 2 kB records
-        instead. SCI Sockets were not tested with 2 kB records. Tests
+        access decreases by a factor of 3 to 4 when using 2KB records
+        instead. SCI Sockets were not tested with 2KB records. Tests
         were performed on a cluster with 2 data nodes running on 2
         dual-CPU machines equipped with AMD MP1900+ processors.
       </para>
@@ -12775,7 +12775,7 @@
           database times the number of replicas, divided by the number
           of data nodes. Thus, if the database takes up 1 gigabyte of
           memory, and you wish to set up the cluster with 4 replicas and
-          8 data nodes, a minimum of 500 MB memory will be required per
+          8 data nodes, a minimum of 500MB memory will be required per
           node. Note that this is in addition to any requirements for
           the operating system and any other applications that might be
           running on the host.

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