| List: | Commits | « Previous MessageNext Message » | |
| From: | paul | Date: | December 18 2005 6:24am |
| Subject: | svn commit - mysqldoc@docsrva: r589 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | ||
| View as plain text | |||
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: + </para> <programlisting> SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345; </programlisting> + <para> takes more time than it <quote>should</quote> take. (In the query above we are <quote>fooling</quote> 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 <quote>black hole</quote> that accepts data but throws it away and does not store it. Retrievals always return the empty set: + </para> <programlisting> mysql> <userinput>CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;</userinput> @@ -3538,7 +3539,6 @@ mysql> <userinput>SELECT * FROM test;</userinput> Empty set (0.00 sec) </programlisting> - </para> <para> When you create a <literal>BLACKHOLE</literal> 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 - <quote>dummy</quote> slave process whose default storage engine is - <literal>BLACKHOLE</literal>, 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 <quote>dummy</quote> slave process whose default storage + engine is <literal>BLACKHOLE</literal>, depicted as follows: </para> <mediaobject> @@ -3591,7 +3591,7 @@ <literal>mysqld</literal> process acts as a slave, applying the desired combination of <literal>replicate-do</literal> and <literal>replicate-ignore</literal> rules, and writes a new, - filtered binlog of its own. (See + filtered binary log of its own. (See <xref linkend="replication-options"/>.) This filtered log is provided to the slave. </para> @@ -3607,34 +3607,34 @@ <para> Other possible uses for the <literal>BLACKHOLE</literal> storage engine include: + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - Verification of dumpfile syntax. - </para> - </listitem> + <listitem> + <para> + Verification of dumpfile syntax. + </para> + </listitem> - <listitem> - <para> - Measurement of the overhead from binary logging, by - comparing performance using <literal>BLACKHOLE</literal> - with and without binary logging enabled. - </para> - </listitem> + <listitem> + <para> + Measurement of the overhead from binary logging, by comparing + performance using <literal>BLACKHOLE</literal> with and + without binary logging enabled. + </para> + </listitem> - <listitem> - <para> - since <literal>BLACKHOLE</literal> is essentially a - <quote>no-op</quote> storage engine, it could be used for - finding performance bottlenecks not related to the storage - engine itself. - </para> - </listitem> + <listitem> + <para> + since <literal>BLACKHOLE</literal> is essentially a + <quote>no-op</quote> storage engine, it could be used for + finding performance bottlenecks not related to the storage + engine itself. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> 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 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>InnoDB</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?22"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>InnoDB</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?22"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -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: + </para> <programlisting> SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345; </programlisting> + <para> takes more time than it <quote>should</quote> take. (In the query above we are <quote>fooling</quote> 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 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>MyISAM</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?21"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>MyISAM</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?21"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> <section id="myisam-start"> @@ -2033,19 +2033,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>MERGE</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?93"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>MERGE</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?93"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -2357,19 +2357,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>MEMORY</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?92"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>MEMORY</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?92"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -3326,19 +3326,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>FEDERATED</literal> storage engine, there's - a dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?105"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>FEDERATED</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?105"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> <section id="federated-install"> @@ -3578,19 +3578,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>FEDERATED</literal> storage engine, - there's a dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?105"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>FEDERATED</literal> storage engine, there's + a dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?105"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -3822,19 +3822,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>ARCHIVE</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?112"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>ARCHIVE</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?112"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -3934,6 +3934,7 @@ The <literal>BLACKHOLE</literal> storage engine acts as a <quote>black hole</quote> that accepts data but throws it away and does not store it. Retrievals always return the empty set: + </para> <programlisting> mysql> <userinput>CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;</userinput> @@ -3946,7 +3947,6 @@ mysql> <userinput>SELECT * FROM test;</userinput> Empty set (0.00 sec) </programlisting> - </para> <para> When you create a <literal>BLACKHOLE</literal> 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 <quote>dummy</quote> slave process whose default storage engine is @@ -3999,7 +3999,7 @@ <literal>mysqld</literal> process acts as a slave, applying the desired combination of <literal>replicate-do</literal> and <literal>replicate-ignore</literal> rules, and writes a new, - filtered binlog of its own. (See + filtered binary log of its own. (See <xref linkend="replication-options"/>.) This filtered log is provided to the slave. </para> @@ -4015,34 +4015,34 @@ <para> Other possible uses for the <literal>BLACKHOLE</literal> storage engine include: + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - Verification of dumpfile syntax. - </para> - </listitem> + <listitem> + <para> + Verification of dumpfile syntax. + </para> + </listitem> - <listitem> - <para> - Measurement of the overhead from binary logging, by - comparing performance using <literal>BLACKHOLE</literal> - with and without binary logging enabled. - </para> - </listitem> + <listitem> + <para> + Measurement of the overhead from binary logging, by comparing + performance using <literal>BLACKHOLE</literal> with and + without binary logging enabled. + </para> + </listitem> - <listitem> - <para> - since <literal>BLACKHOLE</literal> is essentially a - <quote>no-op</quote> storage engine, it could be used for - finding performance bottlenecks not related to the storage - engine itself. - </para> - </listitem> + <listitem> + <para> + since <literal>BLACKHOLE</literal> is essentially a + <quote>no-op</quote> storage engine, it could be used for + finding performance bottlenecks not related to the storage + engine itself. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> 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 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>InnoDB</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?22"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>InnoDB</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?22"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -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: + </para> <programlisting> SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345; </programlisting> + <para> takes more time than it <quote>should</quote> take. (In the query above we are <quote>fooling</quote> 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 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>MyISAM</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?21"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>MyISAM</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?21"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> <section id="myisam-start"> @@ -2033,19 +2033,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>MERGE</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?93"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>MERGE</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?93"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -2357,19 +2357,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>MEMORY</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?92"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>MEMORY</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?92"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -3349,19 +3349,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>FEDERATED</literal> storage engine, there's - a dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?105"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>FEDERATED</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?105"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> <section id="federated-install"> @@ -3603,19 +3603,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>FEDERATED</literal> storage engine, - there's a dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?105"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>FEDERATED</literal> storage engine, there's + a dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?105"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -3846,19 +3846,19 @@ <para> <emphasis role="bold">Additional resources</emphasis> + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - For the <literal>ARCHIVE</literal> storage engine, there's a - dedicated forum available on - <ulink url="http://forums.mysql.com/list.php?112"/>. - </para> - </listitem> + <listitem> + <para> + For the <literal>ARCHIVE</literal> storage engine, there's a + dedicated forum available on + <ulink url="http://forums.mysql.com/list.php?112"/>. + </para> + </listitem> - </itemizedlist> - </para> + </itemizedlist> </section> @@ -3958,6 +3958,7 @@ The <literal>BLACKHOLE</literal> storage engine acts as a <quote>black hole</quote> that accepts data but throws it away and does not store it. Retrievals always return the empty set: + </para> <programlisting> mysql> <userinput>CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;</userinput> @@ -3970,7 +3971,6 @@ mysql> <userinput>SELECT * FROM test;</userinput> Empty set (0.00 sec) </programlisting> - </para> <para> When you create a <literal>BLACKHOLE</literal> 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 - <quote>dummy</quote> slave process whose default storage engine is - <literal>BLACKHOLE</literal>, 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 <quote>dummy</quote> slave process whose default storage + engine is <literal>BLACKHOLE</literal>, depicted as follows: </para> <mediaobject> @@ -4023,7 +4023,7 @@ <literal>mysqld</literal> process acts as a slave, applying the desired combination of <literal>replicate-do</literal> and <literal>replicate-ignore</literal> rules, and writes a new, - filtered binlog of its own. (See + filtered binary log of its own. (See <xref linkend="replication-options"/>.) This filtered log is provided to the slave. </para> @@ -4039,33 +4039,39 @@ <para> Other possible uses for the <literal>BLACKHOLE</literal> storage engine include: + </para> - <itemizedlist> + <itemizedlist> - <listitem> - <para> - Verification of dumpfile syntax. - </para> - </listitem> + <listitem> + <para> + Verification of dumpfile syntax. + </para> + </listitem> - <listitem> - <para> - Measurement of the overhead from binary logging, by - comparing performance using <literal>BLACKHOLE</literal> - with and without binary logging enabled. - </para> - </listitem> + <listitem> + <para> + Measurement of the overhead from binary logging, by comparing + performance using <literal>BLACKHOLE</literal> with and + without binary logging enabled. + </para> + </listitem> - <listitem> - <para> - since <literal>BLACKHOLE</literal> is essentially a - <quote>no-op</quote> storage engine, it could be used for - finding performance bottlenecks not related to the storage - engine itself. - </para> - </listitem> + <listitem> + <para> + since <literal>BLACKHOLE</literal> is essentially a + <quote>no-op</quote> storage engine, it could be used for + finding performance bottlenecks not related to the storage + engine itself. + </para> + </listitem> - </itemizedlist> + </itemizedlist> + + <para> + As of MySQL 5.1.4, the <literal>BLACKHOLE</literal> engine is + transaction-aware in the sense that committed transactions are + written to the binary log, but rolled-back transactions are not. </para> </section>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r589 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 18 Dec |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.694 sec. using MySQL 5.1.14-beta-log