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.1 | paul | 17 Jan |
