From: paul
Date: December 18 2005 5:24am
Subject: svn commit - mysqldoc@docsrva: r589 - in trunk: . refman-4.1 refman-5.0 refman-5.1
List-Archive: http://lists.mysql.com/commits/219
Message-Id: <200512180524.jBI5Ojr2013354@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Author: paul
Date: 2005-12-18 06:24:44 +0100 (Sun, 18 Dec 2005)
New Revision: 589
Log:
r4896@frost: paul | 2005-12-17 23:24:11 -0600
De-cruft.
Modified:
trunk/
trunk/refman-4.1/innodb.xml
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/storage-engines.xml
trunk/refman-5.1/innodb.xml
trunk/refman-5.1/storage-engines.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:4895
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1694
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:4896
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1694
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-4.1/innodb.xml 2005-12-18 05:24:44 UTC (rev 589)
@@ -5847,11 +5847,13 @@
difficult to determine. All InnoDB data and indexes are stored
in B-trees, and their fill factor may vary from 50% to 100%.
Another symptom of fragmentation is that a table scan such as:
+
SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345;
+
takes more time than it should
take. (In the
query above we are fooling
the SQL optimizer into
scanning the clustered index, rather than a secondary index.)
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-4.1/storage-engines.xml 2005-12-18 05:24:44 UTC (rev 589)
@@ -3526,6 +3526,7 @@
4.1.11. This engine acts as a black hole
that
accepts data but throws it away and does not store it. Retrievals
always return the empty set:
+
mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
@@ -3538,7 +3539,6 @@
mysql> SELECT * FROM test;
Empty set (0.00 sec)
-
When you create a BLACKHOLE table, the server
@@ -3569,11 +3569,11 @@
data, but if the binary log is enabled, the SQL statements are
logged (and replicated to slave servers). This can be useful as a
repeater or filter mechanism. For example, suppose that your
- application requires slave-side filtering rules, but transfering
- all binlog data to the slave first results in too much traffic. In
- such a case, it is possible to set up on the master host a
- dummy
slave process whose default storage engine is
- BLACKHOLE, depicted as follows:
+ application requires slave-side filtering rules, but transferring
+ all binary log data to the slave first results in too much
+ traffic. In such a case, it is possible to set up on the master
+ host a dummy
slave process whose default storage
+ engine is BLACKHOLE, depicted as follows:
@@ -3591,7 +3591,7 @@
mysqld process acts as a slave, applying the
desired combination of replicate-do and
replicate-ignore rules, and writes a new,
- filtered binlog of its own. (See
+ filtered binary log of its own. (See
.) This filtered log is
provided to the slave.
@@ -3607,34 +3607,34 @@
Other possible uses for the BLACKHOLE storage
engine include:
+
-
+
-
-
- Verification of dumpfile syntax.
-
-
+
+
+ Verification of dumpfile syntax.
+
+
-
-
- Measurement of the overhead from binary logging, by
- comparing performance using BLACKHOLE
- with and without binary logging enabled.
-
-
+
+
+ Measurement of the overhead from binary logging, by comparing
+ performance using BLACKHOLE with and
+ without binary logging enabled.
+
+
-
-
- since BLACKHOLE is essentially a
- no-op
storage engine, it could be used for
- finding performance bottlenecks not related to the storage
- engine itself.
-
-
+
+
+ since BLACKHOLE is essentially a
+ no-op
storage engine, it could be used for
+ finding performance bottlenecks not related to the storage
+ engine itself.
+
+
-
-
+
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.0/innodb.xml 2005-12-18 05:24:44 UTC (rev 589)
@@ -112,19 +112,19 @@
Additional resources
+
-
+
-
-
- For the InnoDB storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the InnoDB storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -5797,11 +5797,13 @@
difficult to determine. All InnoDB data and indexes are stored
in B-trees, and their fill factor may vary from 50% to 100%.
Another symptom of fragmentation is that a table scan such as:
+
SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345;
+
takes more time than it should
take. (In the
query above we are fooling
the SQL optimizer into
scanning the clustered index, rather than a secondary index.)
Modified: trunk/refman-5.0/storage-engines.xml
===================================================================
--- trunk/refman-5.0/storage-engines.xml 2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.0/storage-engines.xml 2005-12-18 05:24:44 UTC (rev 589)
@@ -728,19 +728,19 @@
Additional resources
+
-
+
-
-
- For the MyISAM storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the MyISAM storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -2033,19 +2033,19 @@
Additional resources
+
-
+
-
-
- For the MERGE storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the MERGE storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -2357,19 +2357,19 @@
Additional resources
+
-
+
-
-
- For the MEMORY storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the MEMORY storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -3326,19 +3326,19 @@
Additional resources
+
-
+
-
-
- For the FEDERATED storage engine, there's
- a dedicated forum available on
- .
-
-
+
+
+ For the FEDERATED storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -3578,19 +3578,19 @@
Additional resources
+
-
+
-
-
- For the FEDERATED storage engine,
- there's a dedicated forum available on
- .
-
-
+
+
+ For the FEDERATED storage engine, there's
+ a dedicated forum available on
+ .
+
+
-
-
+
@@ -3822,19 +3822,19 @@
Additional resources
+
-
+
-
-
- For the ARCHIVE storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the ARCHIVE storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -3934,6 +3934,7 @@
The BLACKHOLE storage engine acts as a
black hole
that accepts data but throws it away and
does not store it. Retrievals always return the empty set:
+
mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
@@ -3946,7 +3947,6 @@
mysql> SELECT * FROM test;
Empty set (0.00 sec)
-
When you create a BLACKHOLE table, the server
@@ -3977,7 +3977,7 @@
data, but if the binary log is enabled, the SQL statements are
logged (and replicated to slave servers). This can be useful as a
repeater or filter mechanism. For example, suppose that your
- application requires slave-side filtering rules, but transfering
+ application requires slave-side filtering rules, but transferring
all binlog data to the slave first results in too much traffic. In
such a case, it is possible to set up on the master host a
dummy
slave process whose default storage engine is
@@ -3999,7 +3999,7 @@
mysqld process acts as a slave, applying the
desired combination of replicate-do and
replicate-ignore rules, and writes a new,
- filtered binlog of its own. (See
+ filtered binary log of its own. (See
.) This filtered log is
provided to the slave.
@@ -4015,34 +4015,34 @@
Other possible uses for the BLACKHOLE storage
engine include:
+
-
+
-
-
- Verification of dumpfile syntax.
-
-
+
+
+ Verification of dumpfile syntax.
+
+
-
-
- Measurement of the overhead from binary logging, by
- comparing performance using BLACKHOLE
- with and without binary logging enabled.
-
-
+
+
+ Measurement of the overhead from binary logging, by comparing
+ performance using BLACKHOLE with and
+ without binary logging enabled.
+
+
-
-
- since BLACKHOLE is essentially a
- no-op
storage engine, it could be used for
- finding performance bottlenecks not related to the storage
- engine itself.
-
-
+
+
+ since BLACKHOLE is essentially a
+ no-op
storage engine, it could be used for
+ finding performance bottlenecks not related to the storage
+ engine itself.
+
+
-
-
+
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.1/innodb.xml 2005-12-18 05:24:44 UTC (rev 589)
@@ -112,19 +112,19 @@
Additional resources
+
-
+
-
-
- For the InnoDB storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the InnoDB storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -5757,11 +5757,13 @@
difficult to determine. All InnoDB data and indexes are stored
in B-trees, and their fill factor may vary from 50% to 100%.
Another symptom of fragmentation is that a table scan such as:
+
SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345;
+
takes more time than it should
take. (In the
query above we are fooling
the SQL optimizer into
scanning the clustered index, rather than a secondary index.)
Modified: trunk/refman-5.1/storage-engines.xml
===================================================================
--- trunk/refman-5.1/storage-engines.xml 2005-12-18 05:24:27 UTC (rev 588)
+++ trunk/refman-5.1/storage-engines.xml 2005-12-18 05:24:44 UTC (rev 589)
@@ -732,19 +732,19 @@
Additional resources
+
-
+
-
-
- For the MyISAM storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the MyISAM storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -2033,19 +2033,19 @@
Additional resources
+
-
+
-
-
- For the MERGE storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the MERGE storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -2357,19 +2357,19 @@
Additional resources
+
-
+
-
-
- For the MEMORY storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the MEMORY storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -3349,19 +3349,19 @@
Additional resources
+
-
+
-
-
- For the FEDERATED storage engine, there's
- a dedicated forum available on
- .
-
-
+
+
+ For the FEDERATED storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -3603,19 +3603,19 @@
Additional resources
+
-
+
-
-
- For the FEDERATED storage engine,
- there's a dedicated forum available on
- .
-
-
+
+
+ For the FEDERATED storage engine, there's
+ a dedicated forum available on
+ .
+
+
-
-
+
@@ -3846,19 +3846,19 @@
Additional resources
+
-
+
-
-
- For the ARCHIVE storage engine, there's a
- dedicated forum available on
- .
-
-
+
+
+ For the ARCHIVE storage engine, there's a
+ dedicated forum available on
+ .
+
+
-
-
+
@@ -3958,6 +3958,7 @@
The BLACKHOLE storage engine acts as a
black hole
that accepts data but throws it away and
does not store it. Retrievals always return the empty set:
+
mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
@@ -3970,7 +3971,6 @@
mysql> SELECT * FROM test;
Empty set (0.00 sec)
-
When you create a BLACKHOLE table, the server
@@ -4001,11 +4001,11 @@
data, but if the binary log is enabled, the SQL statements are
logged (and replicated to slave servers). This can be useful as a
repeater or filter mechanism. For example, suppose that your
- application requires slave-side filtering rules, but transfering
- all binlog data to the slave first results in too much traffic. In
- such a case, it is possible to set up on the master host a
- dummy
slave process whose default storage engine is
- BLACKHOLE, depicted as follows:
+ application requires slave-side filtering rules, but transferring
+ all binary log data to the slave first results in too much
+ traffic. In such a case, it is possible to set up on the master
+ host a dummy
slave process whose default storage
+ engine is BLACKHOLE, depicted as follows:
@@ -4023,7 +4023,7 @@
mysqld process acts as a slave, applying the
desired combination of replicate-do and
replicate-ignore rules, and writes a new,
- filtered binlog of its own. (See
+ filtered binary log of its own. (See
.) This filtered log is
provided to the slave.
@@ -4039,33 +4039,39 @@
Other possible uses for the BLACKHOLE storage
engine include:
+
-
+
-
-
- Verification of dumpfile syntax.
-
-
+
+
+ Verification of dumpfile syntax.
+
+
-
-
- Measurement of the overhead from binary logging, by
- comparing performance using BLACKHOLE
- with and without binary logging enabled.
-
-
+
+
+ Measurement of the overhead from binary logging, by comparing
+ performance using BLACKHOLE with and
+ without binary logging enabled.
+
+
-
-
- since BLACKHOLE is essentially a
- no-op
storage engine, it could be used for
- finding performance bottlenecks not related to the storage
- engine itself.
-
-
+
+
+ since BLACKHOLE is essentially a
+ no-op
storage engine, it could be used for
+ finding performance bottlenecks not related to the storage
+ engine itself.
+
+
-
+
+
+
+ As of MySQL 5.1.4, the BLACKHOLE engine is
+ transaction-aware in the sense that committed transactions are
+ written to the binary log, but rolled-back transactions are not.