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 — 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 — 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 — 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>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r3053 - in trunk: refman-4.1 refman-5.0 refman-5.1 | jon | 18 Aug |
