svn commit - mysqldoc@docsrva: r3053 - in trunk: refman-4.1 refman-5.0 refman-5.1

[jon]

Author: jstephens
Date: 2006-08-18 13:13:40 +0200 (Fri, 18 Aug 2006)
New Revision: 3053

Log:
Reformat.

Modified:
   trunk/refman-4.1/mysql-cluster.xml
   trunk/refman-5.0/mysql-cluster.xml
   trunk/refman-5.1/mysql-cluster.xml


Modified: trunk/refman-4.1/mysql-cluster.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster.xml	2006-08-18 11:11:34 UTC (rev 3052)
+++ trunk/refman-4.1/mysql-cluster.xml	2006-08-18 11:13:40 UTC (rev 3053)
Changed blocks: 2, Lines Added: 13, Lines Deleted: 12; 2588 bytes

@@ -14694,17 +14694,18 @@
             <para>
               Creating a primary key or unique index also creates an
               ordered index, unless this index is created with
-              <literal>USING HASH</literal>. In other words:              
+              <literal>USING HASH</literal>. In other words:
             </para>
-            
+
             <itemizedlist>
+
               <listitem>
                 <para>
                   A primary key or unique index on a Cluster table
                   normally takes up 31 to 35 bytes per record.
                 </para>
               </listitem>
-              
+
               <listitem>
                 <para>
                   However, if the primary key or unique index is created

@@ -14712,22 +14713,22 @@
                   only 21 to 25 bytes per record.
                 </para>
               </listitem>
+
             </itemizedlist>
-                        
+
             <para>
               Note that creating MySQL Cluster tables with
               <literal>USING HASH</literal> for all primary keys and
               unique indexes will generally cause table updates to run
               more quickly &mdash; in some cases by a much as 20 to 30
               percent faster than updates on tables where <literal>USING
-                HASH</literal> was not used in creating primary and
-              unique keys. This is due to the fact that less memory is
-              required (because no ordered indexes are created), and 
-              that less CPU must be utilized (because fewer indexes must
-              be read and possibly updated). However, it also means that
-              queries that could otherwise use range scans must be
-              satisfied by other means, which can result in slower
-              selects.
+              HASH</literal> was not used in creating primary and unique
+              keys. This is due to the fact that less memory is required
+              (because no ordered indexes are created), and that less
+              CPU must be utilized (because fewer indexes must be read
+              and possibly updated). However, it also means that queries
+              that could otherwise use range scans must be satisfied by
+              other means, which can result in slower selects.
             </para>
           </listitem>
 


Modified: trunk/refman-5.0/mysql-cluster.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster.xml	2006-08-18 11:11:34 UTC (rev 3052)
+++ trunk/refman-5.0/mysql-cluster.xml	2006-08-18 11:13:40 UTC (rev 3053)
Changed blocks: 2, Lines Added: 13, Lines Deleted: 12; 2588 bytes

@@ -15041,17 +15041,18 @@
             <para>
               Creating a primary key or unique index also creates an
               ordered index, unless this index is created with
-              <literal>USING HASH</literal>. In other words:              
+              <literal>USING HASH</literal>. In other words:
             </para>
-            
+
             <itemizedlist>
+
               <listitem>
                 <para>
                   A primary key or unique index on a Cluster table
                   normally takes up 31 to 35 bytes per record.
                 </para>
               </listitem>
-              
+
               <listitem>
                 <para>
                   However, if the primary key or unique index is created

@@ -15059,22 +15060,22 @@
                   only 21 to 25 bytes per record.
                 </para>
               </listitem>
+
             </itemizedlist>
-                        
+
             <para>
               Note that creating MySQL Cluster tables with
               <literal>USING HASH</literal> for all primary keys and
               unique indexes will generally cause table updates to run
               more quickly &mdash; in some cases by a much as 20 to 30
               percent faster than updates on tables where <literal>USING
-                HASH</literal> was not used in creating primary and
-              unique keys. This is due to the fact that less memory is
-              required (because no ordered indexes are created), and 
-              that less CPU must be utilized (because fewer indexes must
-              be read and possibly updated). However, it also means that
-              queries that could otherwise use range scans must be
-              satisfied by other means, which can result in slower
-              selects.
+              HASH</literal> was not used in creating primary and unique
+              keys. This is due to the fact that less memory is required
+              (because no ordered indexes are created), and that less
+              CPU must be utilized (because fewer indexes must be read
+              and possibly updated). However, it also means that queries
+              that could otherwise use range scans must be satisfied by
+              other means, which can result in slower selects.
             </para>
           </listitem>
 


Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml	2006-08-18 11:11:34 UTC (rev 3052)
+++ trunk/refman-5.1/mysql-cluster.xml	2006-08-18 11:13:40 UTC (rev 3053)
Changed blocks: 4, Lines Added: 16, Lines Deleted: 15; 3470 bytes

@@ -9791,7 +9791,7 @@
             time, or when it is restarted using the
             <option>--initial</option> option.
           </para>
-          
+
           <para>
             <emphasis>Note</emphasis>: Disk Data files are not removed
             when restarting a node using <literal>--initial</literal>.

@@ -14617,9 +14617,9 @@
 
           <listitem>
             <para>
-              When you add an <literal>UNDO</literal> log file to a 
+              When you add an <literal>UNDO</literal> log file to a
               logfile group using <literal>ADD UNDOFILE
-                '<replaceable>filename</replaceable>'</literal>, a file
+              '<replaceable>filename</replaceable>'</literal>, a file
               with the the name <replaceable>filename</replaceable> is
               created in the
              
<literal>ndb_<replaceable>nodeid</replaceable>_fs</literal>

@@ -17357,17 +17357,18 @@
             <para>
               Creating a primary key or unique index also creates an
               ordered index, unless this index is created with
-              <literal>USING HASH</literal>. In other words:              
+              <literal>USING HASH</literal>. In other words:
             </para>
-            
+
             <itemizedlist>
+
               <listitem>
                 <para>
                   A primary key or unique index on a Cluster table
                   normally takes up 31 to 35 bytes per record.
                 </para>
               </listitem>
-              
+
               <listitem>
                 <para>
                   However, if the primary key or unique index is created

@@ -17375,22 +17376,22 @@
                   only 21 to 25 bytes per record.
                 </para>
               </listitem>
+
             </itemizedlist>
-                        
+
             <para>
               Note that creating MySQL Cluster tables with
               <literal>USING HASH</literal> for all primary keys and
               unique indexes will generally cause table updates to run
               more quickly &mdash; in some cases by a much as 20 to 30
               percent faster than updates on tables where <literal>USING
-                HASH</literal> was not used in creating primary and
-              unique keys. This is due to the fact that less memory is
-              required (because no ordered indexes are created), and 
-              that less CPU must be utilized (because fewer indexes must
-              be read and possibly updated). However, it also means that
-              queries that could otherwise use range scans must be
-              satisfied by other means, which can result in slower
-              selects.
+              HASH</literal> was not used in creating primary and unique
+              keys. This is due to the fact that less memory is required
+              (because no ordered indexes are created), and that less
+              CPU must be utilized (because fewer indexes must be read
+              and possibly updated). However, it also means that queries
+              that could otherwise use range scans must be satisfied by
+              other means, which can result in slower selects.
             </para>
           </listitem>