List:Commits« Previous MessageNext Message »
From:paul.dubois Date:December 7 2010 8:18pm
Subject:svn commit - mysqldoc@docsrva: r24305 - in trunk: . dynamic-docs/changelog dynamic-docs/glossary innodb-1.1 innodb-plugin-1.1 refman-5.5 refman-5.6 re...
View as plain text  
Author: paul
Date: 2010-12-07 21:18:11 +0100 (Tue, 07 Dec 2010)
New Revision: 24305

Log:
 r45180@arctic:  paul | 2010-12-07 14:13:05 -0600
 Document bug fix:
 - Bug#58798: SHOW ENGINE PERFORMANCE_SCHEMA STATUS: incorrect table lettercase


Modified:
   trunk/dynamic-docs/changelog/mysqld-2.xml
   trunk/dynamic-docs/glossary/innodb.xml
   trunk/innodb-1.1/innodb-performance.xml
   trunk/innodb-plugin-1.1/innodb-performance.xml
   trunk/refman-5.5/optimization.xml
   trunk/refman-5.5/performance-schema-core.xml
   trunk/refman-5.5/restrictions.xml
   trunk/refman-5.5/se-innodb-core.xml
   trunk/refman-5.5/sql-syntax-server-administration.xml
   trunk/refman-5.5/triggers.xml
   trunk/refman-5.6/performance-schema-core.xml
   trunk/refman-5.6/restrictions.xml
   trunk/refman-5.6/sql-syntax-server-administration.xml
   trunk/refman-5.6/triggers.xml
   trunk/refman-6.0/performance-schema-core.xml
   trunk/refman-6.0/restrictions.xml
   trunk/refman-6.0/sql-syntax-server-administration.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:45172
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:66486
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
   + 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:45180
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:66486
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546


Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 2, Lines Added: 47, Lines Deleted: 1; 2063 bytes

@@ -33039,7 +33039,7 @@
 
       <para>
         The following changes were made to the
-        <literal>PERFORMANCE_SCHEMA.THREADS</literal> table for
+        <literal>performance_schema.threads</literal> table for
         conformance with the implementation in MySQL 5.6:
       </para>
 

@@ -33561,4 +33561,50 @@
 
   </logentry>
 
+  <logentry entrytype="bug">
+
+    <tags>
+      <highlight type="incompatiblechange"/>
+      <manual type="Performance Schema"/>
+    </tags>
+
+    <bugs>
+      <fixes bugid="57609"/>
+    </bugs>
+
+    <versions>
+      <version ver="5.5.8"/>
+    </versions>
+
+    <message>
+
+      <para>
+        Previously, tables in the <literal>performance_schema</literal>
+        database had uppercase names. This was incompatible with the
+        <literal role="sysvar">lowercase_table_names</literal> system
+        variable, and caused issues the variable value was changed
+        <emphasis>after</emphasis> installing or upgrading.
+      </para>
+
+      <para>
+        Now <literal>performance_schema</literal> table names are
+        lowercase, so they appear in uniform lettercase regardless of
+        the <literal role="sysvar">lowercase_table_names</literal>
+        setting. References to these tables in SQL statements should be
+        given in lowercase. This is an incompatible change, but provides
+        compatible behavior across different values of
+        <literal role="sysvar">lower_case_table_names</literal>.
+      </para>
+
+      <para>
+        If you upgrade to MySQL 5.5.8 from an earlier version of MySQL
+        5.5, be sure to run <command>mysql_upgrade</command> to change
+        the names of existing <literal>performance_schema</literal>
+        tables from uppercase to lowercase.
+      </para>
+
+    </message>
+
+  </logentry>
+
 </changelog>


Modified: trunk/dynamic-docs/glossary/innodb.xml
===================================================================
--- trunk/dynamic-docs/glossary/innodb.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/dynamic-docs/glossary/innodb.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 582, Lines Added: 1, Lines Deleted: 1173; 110328 bytes

@@ -5,7 +5,6 @@
   <glossent id="aio" class="acronym">
 
     <gterm>AIO</gterm>
-
     <def>
 
       <para>

@@ -14,7 +13,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="asynchronous_io" />
 
   </glossent>

@@ -22,7 +20,6 @@
   <glossent id="acid">
 
     <gterm>ACID</gterm>
-
     <def>
 
       <para>

@@ -32,7 +29,6 @@
         <emphasis role="bold">transaction</emphasis>. The transactional
         features of InnoDB adhere to the ACID principles.
       </para>
-
       <para>
         Transactions are atomic units of work that can be committed or
         rolled back. When a transaction makes multiple changes to the

@@ -40,12 +36,10 @@
         committed, or all the changes are undone when the transaction is
         rolled back.
       </para>
-
       <para>
         The database remains in a consistent state at all times -- after
         each commit or rollback, and while transactions are in progress.
       </para>
-
       <para>
         Transactions are protected (isolated) from each other while they
         are in progress; they cannot interfere with each other or see

@@ -56,7 +50,6 @@
         increased performance, when they can be sure that the
         transactions really do not interfere with each other.)
       </para>
-
       <para>
         The results of transactions are durable: once a commit operation
         succeeds, the changes made by that transaction are safe from

@@ -70,17 +63,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="rollback" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="doublewrite_buffer" />
 
   </glossent>

@@ -88,7 +75,6 @@
   <glossent id="adaptive_flushing">
 
     <gterm>adaptive flushing</gterm>
-
     <def>
 
       <para>

@@ -106,15 +92,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="flush" />
-
     <gseealso glosid="plugin" />
-
     <gseealso glosid="checkpoint" />
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="data_files" />
 
   </glossent>

@@ -122,7 +103,6 @@
   <glossent id="adaptive_hash_index">
 
     <gterm>adaptive hash index</gterm>
-
     <def>
 
       <para>

@@ -132,7 +112,6 @@
         defined for a table. If InnoDB notices that queries could
         benefit from a hash index, it builds one automatically.
       </para>
-
       <para>
         The hash index is always built based on an existing
         <emphasis role="bold">B-tree</emphasis> index on the table.

@@ -143,7 +122,6 @@
         the buffer pool. InnoDB builds hash indexes on demand for those
         pages of the index that are often accessed.
       </para>
-
       <para>
         In a sense, the adaptive hash index configures InnoDB at runtime
         to take advantage of ample main memory, coming closer to the

@@ -151,7 +129,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="b_tree" />
 
   </glossent>

@@ -159,7 +136,6 @@
   <glossent id="antelope">
 
     <gterm>Antelope</gterm>
-
     <def>
 
       <para>

@@ -172,35 +148,24 @@
         available in the <emphasis role="bold">Barracuda</emphasis> file
         format.
       </para>
-
       <para>
         You can select the file format to use through the
         <literal>innodb_file_format</literal> option.
       </para>
-
       <para>
         The default InnoDB file format switches to Barracuda in MySQL
         5.5.5.
       </para>
 
     </def>
-
     <gseealso glosid="barracuda" />
-
     <gseealso glosid="file_format" />
-
     <gseealso glosid="ibdata_file" />
-
     <gseealso glosid="redundant_row_format" />
-
     <gseealso glosid="compact_row_format" />
-
     <gseealso glosid="dynamic_row_format" />
-
     <gseealso glosid="compressed_row_format" />
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="innodb_file_format" />
 
   </glossent>

@@ -208,7 +173,6 @@
   <glossent id="application_programming_interface">
 
     <gterm>application programming interface (API)</gterm>
-
     <def>
 
       <para>

@@ -224,7 +188,6 @@
   <glossent id="apply">
 
     <gterm>apply</gterm>
-
     <def>
 
       <para>

@@ -237,7 +200,6 @@
         <literal>ibbackup</literal> or <literal>innobackup</literal>
         commands.
       </para>
-
       <para>
         Before the changes are applied, we refer to the files as a
         <emphasis role="bold">raw backup</emphasis>. After the changes

@@ -249,15 +211,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="raw_backup" />
-
     <gseealso glosid="prepared_backup" />
-
     <gseealso glosid="ibbackup_logfile" />
 
   </glossent>

@@ -265,7 +222,6 @@
   <glossent id="arm_file">
 
     <gterm>.ARM file</gterm>
-
     <def>
 
       <para>

@@ -277,11 +233,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
-
     <gseealso glosid="arz_file" />
 
   </glossent>

@@ -289,7 +242,6 @@
   <glossent id="arz_file">
 
     <gterm>.ARZ file</gterm>
-
     <def>
 
       <para>

@@ -301,11 +253,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
-
     <gseealso glosid="arm_file" />
 
   </glossent>

@@ -313,7 +262,6 @@
   <glossent id="asynchronous_io">
 
     <gterm>asynchronous I/O</gterm>
-
     <def>
 
       <para>

@@ -327,7 +275,6 @@
         pool</emphasis> that have not actually been requested, but might
         be needed soon.
       </para>
-
       <para>
         Historically, InnoDB has used asynchronous I/O on Windows
         systems only. Starting with the InnoDB Plugin 1.1, InnoDB uses

@@ -337,9 +284,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="non_blocking_io" />
-
     <gseealso glosid="buffer_pool" />
 
   </glossent>

@@ -347,7 +292,6 @@
   <glossent id="autocommit">
 
     <gterm>autocommit</gterm>
-
     <def>
 
       <para>

@@ -364,15 +308,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="undo" />
 
   </glossent>

@@ -380,7 +319,6 @@
   <glossent id="auto_increment">
 
     <gterm>auto-increment</gterm>
-
     <def>
 
       <para>

@@ -390,7 +328,6 @@
         supports auto-increment only for <emphasis role="bold">primary
         key</emphasis> columns.
       </para>
-
       <para>
         It saves work for the developer, not to have to produce new
         unique values when inserting new rows. It provides useful

@@ -401,7 +338,6 @@
         change them; for this reason, primary key columns are often
         specified as auto-incrementing.
       </para>
-
       <para>
         Auto-increment columns can be problematic with statement-based
         replication, because replaying the statements on a slave might

@@ -420,19 +356,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="primary_key" />
-
     <gseealso glosid="auto_increment_locking" />
-
     <gseealso glosid="statement_based_replication" />
-
     <gseealso glosid="row_based_replication" />
-
     <gseealso glosid="innodb_autoinc_lock_mode" />
-
     <gseealso glosid="row_based_replication" />
-
     <gseealso glosid="statement_based_replication" />
 
   </glossent>

@@ -440,7 +369,6 @@
   <glossent id="auto_increment_locking">
 
     <gterm>auto-increment locking</gterm>
-
     <def>
 
       <para>

@@ -459,11 +387,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="auto_increment" />
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="innodb_autoinc_lock_mode" />
 
   </glossent>

@@ -471,7 +396,6 @@
   <glossent id="backticks">
 
     <gterm>backticks</gterm>
-
     <def>
 
       <para>

@@ -485,7 +409,6 @@
         used extensively in program-generated SQL statements, where the
         identifier names might not be known in advance.
       </para>
-
       <para>
         Many other database systems use double quotation marks
         (<literal>"</literal>) around such special names. For

@@ -495,7 +418,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="sql" />
 
   </glossent>

@@ -503,7 +425,6 @@
   <glossent id="barracuda">
 
     <gterm>Barracuda</gterm>
-
     <def>
 
       <para>

@@ -515,12 +436,10 @@
         select it through the <literal>innodb_file_format</literal>
         option.
       </para>
-
       <para>
         The default InnoDB file format switches to Barracuda in MySQL
         5.5.5.
       </para>
-
       <para>
         The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
         product version 3.5 and above supports backing up tablespaces

@@ -528,21 +447,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="antelope" />
-
     <gseealso glosid="file_format" />
-
     <gseealso glosid="ibdata_file" />
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="compact_row_format" />
-
     <gseealso glosid="compressed_row_format" />
-
     <gseealso glosid="dynamic_row_format" />
-
     <gseealso glosid="innodb_file_format" />
 
   </glossent>

@@ -550,7 +461,6 @@
   <glossent id="beta">
 
     <gterm>beta</gterm>
-
     <def>
 
       <para>

@@ -564,9 +474,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="early_adopter" />
-
     <gseealso glosid="ga" />
 
   </glossent>

@@ -574,7 +482,6 @@
   <glossent id="bottleneck">
 
     <gterm>bottleneck</gterm>
-
     <def>
 
       <para>

@@ -587,9 +494,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="buffer_pool" />
 
   </glossent>

@@ -597,7 +502,6 @@
   <glossent id="buffer">
 
     <gterm>buffer</gterm>
-
     <def>
 
       <para>

@@ -614,11 +518,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="doublewrite_buffer" />
-
     <gseealso glosid="insert_buffer" />
 
   </glossent>

@@ -626,7 +527,6 @@
   <glossent id="buffer_pool">
 
     <gterm>buffer pool</gterm>
-
     <def>
 
       <para>

@@ -643,9 +543,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="page" />
-
     <gseealso glosid="lru" />
 
   </glossent>

@@ -653,7 +551,6 @@
   <glossent id="b_tree">
 
     <gterm>B-tree</gterm>
-
     <def>
 
       <para>

@@ -664,12 +561,10 @@
         operators). This type of index is available for most storage
         engines, such as InnoDB and MyISAM.
       </para>
-
       <para>
         Because B-tree nodes can have many children, a B-tree is not the
         same as a binary tree, which is limited to 2 children per node.
       </para>
-
       <para>
         Contrast with <emphasis role="bold">hash index</emphasis>, which
         is only available in the MEMORY storage engine. The MEMORY

@@ -679,7 +574,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="hash_index" />
 
   </glossent>

@@ -687,7 +581,6 @@
   <glossent id="binary_log">
 
     <gterm>binary log</gterm>
-
     <def>
 
       <para>

@@ -699,13 +592,11 @@
         recommend always enabling it if you use replication or perform
         backups.
       </para>
-
       <para>
         You can examine the contents of the binary log, or replay those
         statements during replication or recovery, by using the
         <literal>mysqlbinlog</literal> command.
       </para>
-
       <para>
         For the <emphasis role="bold">MySQL Enterprise Backup</emphasis>
         product, the file name of the binary log and the current

@@ -714,7 +605,6 @@
         replication context, you can specify the
         <literal>--slave-info</literal> option.
       </para>
-
       <para>
         Prior to MySQL 5.0, a similar capability was available, known as
         the update log. In MySQL 5.0 and higher, the binary log replaces

@@ -722,7 +612,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="binlog" />
 
   </glossent>

@@ -730,7 +619,6 @@
   <glossent id="binlog">
 
     <gterm>binlog</gterm>
-
     <def>
 
       <para>

@@ -740,7 +628,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="binary_log" />
 
   </glossent>

@@ -748,7 +635,6 @@
   <glossent id="built_in">
 
     <gterm>built-in</gterm>
-
     <def>
 
       <para>

@@ -761,7 +647,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="plugin" />
 
   </glossent>

@@ -769,7 +654,6 @@
   <glossent id="business_rules">
 
     <gterm>business rules</gterm>
-
     <def>
 
       <para>

@@ -781,7 +665,6 @@
         through application logic, accurately reflect the real policies
         of the company and can handle real-life situations.
       </para>
-
       <para>
         For example, an employee leaving a company might trigger a
         sequence of actions from the human resources department. The

@@ -800,9 +683,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="relational" />
-
     <gseealso glosid="trigger" />
 
   </glossent>

@@ -810,7 +691,6 @@
   <glossent id="change_buffering">
 
     <gterm>change buffering</gterm>
-
     <def>
 
       <para>

@@ -828,13 +708,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="insert_buffer" />
-
     <gseealso glosid="insert_buffering" />
-
     <gseealso glosid="delete_buffering" />
-
     <gseealso glosid="purge_buffering" />
 
   </glossent>

@@ -842,7 +718,6 @@
   <glossent id="checkpoint">
 
     <gterm>checkpoint</gterm>
-
     <def>
 
       <para>

@@ -857,13 +732,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="flush" />
-
     <gseealso glosid="lsn" />
-
     <gseealso glosid="data_files" />
 
   </glossent>

@@ -871,7 +742,6 @@
   <glossent id="child_table">
 
     <gterm>child table</gterm>
-
     <def>
 
       <para>

@@ -887,9 +757,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="foreign_key" />
-
     <gseealso glosid="parent_table" />
 
   </glossent>

@@ -897,7 +765,6 @@
   <glossent id="cold_backup">
 
     <gterm>cold backup</gterm>
-
     <def>
 
       <para>

@@ -909,11 +776,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="backup" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="warm_backup" />
 
   </glossent>

@@ -921,7 +785,6 @@
   <glossent id="column_index">
 
     <gterm>column index</gterm>
-
     <def>
 
       <para>

@@ -929,9 +792,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="composite_index" />
 
   </glossent>

@@ -939,7 +800,6 @@
   <glossent id="compressed_backup">
 
     <gterm>compressed backup</gterm>
-
     <def>
 
       <para>

@@ -949,7 +809,6 @@
         compressed files are renamed with a <literal>.ibz</literal> file
         extension.
       </para>
-
       <para>
         Applying <emphasis role="bold">compression</emphasis> right at
         the start of the backup process helps to avoid storage overhead

@@ -961,17 +820,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="compression" />
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="apply" />
-
     <gseealso glosid="binary_log" />
 
   </glossent>

@@ -979,7 +832,6 @@
   <glossent id="compression">
 
     <gterm>compression</gterm>
-
     <def>
 
       <para>

@@ -991,7 +843,6 @@
         with the <emphasis role="bold">MySQL Enterprise
         Backup</emphasis> product.
       </para>
-
       <para>
         When InnoDB table data is compressed, the compression applies to
         the <emphasis role="bold">table</emphasis> itself, any

@@ -1000,7 +851,6 @@
         pool</emphasis>. Compression does not apply to pages in the
         <emphasis role="bold">undo buffer</emphasis>.
       </para>
-
       <para>
         The table compression feature requires using MySQL 5.5 or
         higher, or the InnoDB Plugin in MySQL 5.1 or earlier, and

@@ -1010,7 +860,6 @@
         <emphasis role="bold">innodb_file_per_table</emphasis> setting
         turned on.
       </para>
-
       <para>
         The compression feature of the <emphasis role="bold">MySQL
         Enterprise Backup</emphasis> product makes a compressed copy of

@@ -1026,21 +875,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="table" />
-
     <gseealso glosid="index" />
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="undo_buffer" />
-
     <gseealso glosid="plugin" />
-
     <gseealso glosid="barracuda" />
-
     <gseealso glosid="compressed_row_format" />
-
     <gseealso glosid="hot_backup" />
 
   </glossent>

@@ -1048,7 +889,6 @@
   <glossent id="constraint">
 
     <gterm>constraint</gterm>
-
     <def>
 
       <para>

@@ -1063,13 +903,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="relational" />
-
     <gseealso glosid="foreign_key" />
-
     <gseealso glosid="unique_constraint" />
 
   </glossent>

@@ -1077,7 +913,6 @@
   <glossent id="concatenated_index">
 
     <gterm>concatenated index</gterm>
-
     <gsee glosid="composite_index" />
 
   </glossent>

@@ -1085,7 +920,6 @@
   <glossent id="commit">
 
     <gterm>commit</gterm>
-
     <def>
 
       <para>

@@ -1095,7 +929,6 @@
         <emphasis role="bold">rollback</emphasis>, which undoes any
         changes made in the transaction.
       </para>
-
       <para>
         InnoDB uses an <emphasis role="bold">optimistic</emphasis>
         mechanism for commits, so that changes can be written to the

@@ -1103,7 +936,6 @@
         makes the commit itself faster, with the tradeoff that more work
         is required in case of a rollback.
       </para>
-
       <para>
         By default, MySQL uses the
         <emphasis role="bold">autocommit</emphasis> setting, which

@@ -1111,15 +943,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="rollback" />
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="optimistic" />
-
     <gseealso glosid="autocommit" />
 
   </glossent>

@@ -1127,7 +954,6 @@
   <glossent id="compact_row_format">
 
     <gterm>compact row format</gterm>
-
     <def>
 
       <para>

@@ -1136,7 +962,6 @@
         nulls and variable-length fields than the prior default
         (<emphasis role="bold">redundant row format</emphasis>).
       </para>
-
       <para>
         Because of the <emphasis role="bold">B-tree</emphasis> indexes
         that make row lookups so fast in InnoDB, there is little if any

@@ -1144,9 +969,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="redundant_row_format" />
 
   </glossent>

@@ -1154,7 +977,6 @@
   <glossent id="composite_index">
 
     <gterm>composite index</gterm>
-
     <def>
 
       <para>

@@ -1163,9 +985,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="index_prefix" />
 
   </glossent>

@@ -1173,7 +993,6 @@
   <glossent id="compressed_row_format">
 
     <gterm>compressed row format</gterm>
-
     <def>
 
       <para>

@@ -1189,11 +1008,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="dynamic_row_format" />
-
     <gseealso glosid="barracuda" />
 
   </glossent>

@@ -1201,7 +1017,6 @@
   <glossent id="covering_index">
 
     <gterm>covering index</gterm>
-
     <def>
 
       <para>

@@ -1215,7 +1030,6 @@
         cannot apply this technique for queries against tables modified
         by a transactions, until that transaction ends.
       </para>
-
       <para>
         Any <emphasis role="bold">column index</emphasis> or
         <emphasis role="bold">composite index</emphasis> could act as a

@@ -1225,13 +1039,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="column_index" />
-
     <gseealso glosid="composite_index" />
-
     <gseealso glosid="secondary_index" />
 
   </glossent>

@@ -1239,7 +1049,6 @@
   <glossent id="clustered_index">
 
     <gterm>clustered index</gterm>
-
     <def>
 
       <para>

@@ -1252,18 +1061,14 @@
         the clustered index is an expensive operation, choose primary
         columns that are rarely or never updated.
       </para>
-
       <para>
         In the Oracle Database product, this type of table is known as
         an <emphasis role="bold">index-organized table</emphasis>.
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="primary_key" />
-
     <gseealso glosid="secondary_index" />
 
   </glossent>

@@ -1271,7 +1076,6 @@
   <glossent id="cursor">
 
     <gterm>cursor</gterm>
-
     <def>
 
       <para>

@@ -1281,7 +1085,6 @@
         in other high-level languages, producing each value from the
         result set as requested.
       </para>
-
       <para>
         Although usually SQL handles the processing of cursors for you,
         you might delve into the inner workings when dealing with

@@ -1289,7 +1092,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="query" />
 
   </glossent>

@@ -1297,7 +1099,6 @@
   <glossent id="client">
 
     <gterm>client</gterm>
-
     <def>
 
       <para>

@@ -1309,9 +1110,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="server" />
-
     <gseealso glosid="mysql" />
 
   </glossent>

@@ -1319,7 +1118,6 @@
   <glossent id="configuration_file">
 
     <gterm>configuration file</gterm>
-
     <def>
 
       <para>

@@ -1330,7 +1128,6 @@
         number of options related to InnoDB under the
         <literal>[mysqld]</literal> section of the file.
       </para>
-
       <para>
         When you use the <emphasis role="bold">MySQL Enterprise
         Backup</emphasis> product, you typically use two configuration

@@ -1347,9 +1144,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="option_file" />
-
     <gseealso glosid="my_cnf" />
 
   </glossent>

@@ -1357,7 +1152,6 @@
   <glossent id="cardinality">
 
     <gterm>cardinality</gterm>
-
     <def>
 
       <para>

@@ -1369,7 +1163,6 @@
         cardinality might not be a good way to determine the best query
         plan. (http://bugs.mysql.com/bug.php?id=36513)
       </para>
-
       <para>
         Cardinality can also apply to the number of distinct values
         present in multiple columns, as in a

@@ -1377,13 +1170,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="random_dive" />
-
     <gseealso glosid="index" />
-
     <gseealso glosid="composite_index" />
-
     <gseealso glosid="selectivity" />
 
   </glossent>

@@ -1391,7 +1180,6 @@
   <glossent id="crash_recovery">
 
     <gterm>crash recovery</gterm>
-
     <def>
 
       <para>

@@ -1403,7 +1191,6 @@
         is performed during shutdown by the
         <emphasis role="bold">purge</emphasis> operation.
       </para>
-
       <para>
         During normal operation, committed data can be stored in the
         insert buffer for a period of time before being written to the

@@ -1414,11 +1201,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="purge" />
-
     <gseealso glosid="doublewrite_buffer" />
-
     <gseealso glosid="insert_buffer" />
 
   </glossent>

@@ -1426,7 +1210,6 @@
   <glossent id="cache">
 
     <gterm>cache</gterm>
-
     <def>
 
       <para>

@@ -1437,9 +1220,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="buffer" />
 
   </glossent>

@@ -1447,7 +1228,6 @@
   <glossent id="consistent_read">
 
     <gterm>consistent read</gterm>
-
     <def>
 
       <para>

@@ -1461,7 +1241,6 @@
         can reduce <emphasis role="bold">concurrency</emphasis> by
         forcing transactions to wait for other transactions to finish.
       </para>
-
       <para>
         With the <emphasis role="bold">repeatable read</emphasis>
         isolation level, the snapshot is based on the time when the

@@ -1470,7 +1249,6 @@
         the snapshot is reset to the time of each consistent read
         operation.
       </para>
-
       <para>
         Consistent read is the default mode in which InnoDB processes
         <literal>SELECT</literal> statements in

@@ -1482,27 +1260,16 @@
       </para>
 
     </def>
-
     <gseealso glosid="undo_log" />
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="mvcc" />
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="read_committed" />
-
     <gseealso glosid="read_uncommitted" />
-
     <gseealso glosid="serializable_read" />
 
   </glossent>

@@ -1510,7 +1277,6 @@
   <glossent id="concurrency">
 
     <gterm>concurrency</gterm>
-
     <def>
 
       <para>

@@ -1524,11 +1290,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -1536,7 +1299,6 @@
   <glossent id="column_prefix">
 
     <gterm>column prefix</gterm>
-
     <def>
 
       <para>

@@ -1549,7 +1311,6 @@
         making rows with different values appear to the query optimizer
         to be duplicates.)
       </para>
-
       <para>
         For columns containing binary values or long text strings, where
         sorting is not a major consideration and storing the entire

@@ -1559,7 +1320,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
 
   </glossent>

@@ -1567,7 +1327,6 @@
   <glossent id="data_definition_language">
 
     <gterm>data definition language</gterm>
-
     <gsee glosid="ddl" />
 
   </glossent>

@@ -1575,7 +1334,6 @@
   <glossent id="data_dictionary">
 
     <gterm>data dictionary</gterm>
-
     <def>
 
       <para>

@@ -1584,7 +1342,6 @@
         and table columns. These tables are part of the InnoDB
         <emphasis role="bold">system tablespace</emphasis>.
       </para>
-
       <para>
         Because the <emphasis role="bold">MySQL Enterprise
         Backup</emphasis> product always backs up the system tablespace,

@@ -1592,9 +1349,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="hot_backup" />
 
   </glossent>

@@ -1602,7 +1357,6 @@
   <glossent id="data_manipulation_language">
 
     <gterm>data manipulation language</gterm>
-
     <gsee glosid="dml" />
 
   </glossent>

@@ -1610,7 +1364,6 @@
   <glossent id="data_warehouse">
 
     <gterm>data warehouse</gterm>
-
     <def>
 
       <para>

@@ -1622,9 +1375,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="query" />
-
     <gseealso glosid="oltp" />
 
   </glossent>

@@ -1632,7 +1383,6 @@
   <glossent id="ddl">
 
     <gterm>DDL</gterm>
-
     <def>
 
       <para>

@@ -1646,7 +1396,6 @@
         FROM <replaceable>table_name</replaceable></literal> statement,
         even though the ultimate effect is similar.
       </para>
-
       <para>
         DDL statements automatically
         <emphasis role="bold">commit</emphasis> the current

@@ -1655,13 +1404,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="rollback" />
 
   </glossent>

@@ -1669,7 +1414,6 @@
   <glossent id="dirty_page">
 
     <gterm>dirty page</gterm>
-
     <def>
 
       <para>

@@ -1680,13 +1424,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="page" />
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="flush" />
-
     <gseealso glosid="write_combining" />
 
   </glossent>

@@ -1694,7 +1434,6 @@
   <glossent id="dirty_read">
 
     <gterm>dirty read</gterm>
-
     <def>
 
       <para>

@@ -1704,7 +1443,6 @@
         with the <emphasis role="bold">isolation level</emphasis> known
         as <emphasis role="bold">read uncommitted</emphasis>.
       </para>
-
       <para>
         This kind of operation does not adhere to the
         <emphasis role="bold">ACID</emphasis> principle of database

@@ -1713,7 +1451,6 @@
         before being committed; then, the transaction doing the dirty
         read would be using data that was never confirmed as accurate.
       </para>
-
       <para>
         Its polar opposite is <emphasis role="bold">consistent
         read</emphasis>, where InnoDB goes to great lengths to ensure

@@ -1723,19 +1460,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="rollback" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="read_uncommitted" />
-
     <gseealso glosid="read_committed" />
 
   </glossent>

@@ -1743,7 +1473,6 @@
   <glossent id="dml">
 
     <gterm>DML</gterm>
-
     <def>
 
       <para>

@@ -1757,7 +1486,6 @@
         <literal>INSERT</literal>, <literal>UPDATE</literal>, and
         <literal>DELETE</literal>.
       </para>
-
       <para>
         DML statements operate in the context of a
         <emphasis role="bold">transaction</emphasis>, so their effects

@@ -1766,15 +1494,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="rollback" />
 
   </glossent>

@@ -1782,7 +1505,6 @@
   <glossent id="dynamic_row_format">
 
     <gterm>dynamic row format</gterm>
-
     <def>
 
       <para>

@@ -1796,9 +1518,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="barracuda" />
 
   </glossent>

@@ -1806,7 +1526,6 @@
   <glossent id="delete">
 
     <gterm>delete</gterm>
-
     <def>
 
       <para>

@@ -1819,7 +1538,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="purge" />
 
   </glossent>

@@ -1827,7 +1545,6 @@
   <glossent id="delete_buffering">
 
     <gterm>delete buffering</gterm>
-
     <def>
 
       <para>

@@ -1844,13 +1561,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="change_buffering" />
-
     <gseealso glosid="insert_buffer" />
-
     <gseealso glosid="insert_buffering" />
-
     <gseealso glosid="purge_buffering" />
 
   </glossent>

@@ -1858,13 +1571,11 @@
   <glossent id="descending_index">
 
     <gterm>descending index</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="index" />
 
   </glossent>

@@ -1872,7 +1583,6 @@
   <glossent id="doublewrite_buffer">
 
     <gterm>doublewrite buffer</gterm>
-
     <def>
 
       <para>

@@ -1886,7 +1596,6 @@
         find a good copy of the page from the doublewrite buffer during
         <emphasis role="bold">crash recovery</emphasis>.
       </para>
-
       <para>
         Although data is always written twice, the doublewrite buffer
         does not require twice as much I/O overhead or twice as many I/O

@@ -1894,16 +1603,13 @@
         sequential chunk, with a single <literal>fsync</literal> call to
         the operating system.
       </para>
-
       <para>
         The doublewrite buffer can be turned off by specifying the
         option <literal>innodb_doublewrite=0</literal>.
       </para>
 
     </def>
-
     <gseealso glosid="crash_recovery" />
-
     <gseealso glosid="purge" />
 
   </glossent>

@@ -1911,7 +1617,6 @@
   <glossent id="disk_based">
 
     <gterm>disk-based</gterm>
-
     <def>
 
       <para>

@@ -1923,7 +1628,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="in_memory_database" />
 
   </glossent>

@@ -1931,7 +1635,6 @@
   <glossent id="data_files">
 
     <gterm>data files</gterm>
-
     <def>
 
       <para>

@@ -1948,13 +1651,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="file_per_table" />
 
   </glossent>

@@ -1962,14 +1661,12 @@
   <glossent id="database">
 
     <gterm>database</gterm>
-
     <def>
 
       <para>
         An InnoDB database is largely defined by its
         <emphasis role="bold">data files</emphasis>.
       </para>
-
       <para>
         For long-time MySQL users, a database is a familiar notion.
         Users coming from an Oracle background will find that the MySQL

@@ -1977,7 +1674,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="data_files" />
 
   </glossent>

@@ -1985,7 +1681,6 @@
   <glossent id="deadlock">
 
     <gterm>deadlock</gterm>
-
     <def>
 
       <para>

@@ -1996,7 +1691,6 @@
         Because both transactions are waiting for a resource to become
         available, neither will ever release the locks it holds.
       </para>
-
       <para>
         A deadlock can occur when the transactions acquire locks on
         multiple tables, but in the opposite order. A deadlock can also

@@ -2006,7 +1700,6 @@
         transaction acquiring some locks but not others due to a timing
         issue.
       </para>
-
       <para>
         To reduce the possibility of deadlocks, use transactions rather
         than <literal>LOCK TABLE</literal> statements; keep transactions

@@ -2022,7 +1715,6 @@
         isolation level changes the behavior of read operations, while
         deadlocks occur because of write operations.
       </para>
-
       <para>
         If a deadlock does occur, InnoDB detects the condition and
         <emphasis role="bold">rolls back</emphasis> one of the

@@ -2034,21 +1726,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="gap" />
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="rollback" />
-
     <gseealso glosid="victim" />
 
   </glossent>

@@ -2056,7 +1740,6 @@
   <glossent id="deadlock_detection">
 
     <gterm>deadlock detection</gterm>
-
     <def>
 
       <para>

@@ -2068,13 +1751,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="deadlock" />
-
     <gseealso glosid="rollback" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="victim" />
 
   </glossent>

@@ -2082,7 +1761,6 @@
   <glossent id="early_adopter">
 
     <gterm>early adopter</gterm>
-
     <def>
 
       <para>

@@ -2096,9 +1774,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="beta" />
-
     <gseealso glosid="ga" />
 
   </glossent>

@@ -2106,7 +1782,6 @@
   <glossent id="embedded_innodb">
 
     <gterm>Embedded InnoDB</gterm>
-
     <def>
 
       <para>

@@ -2120,7 +1795,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="cursor" />
 
   </glossent>

@@ -2128,7 +1802,6 @@
   <glossent id="explicit_row_lock">
 
     <gterm>explicit row lock</gterm>
-
     <def>
 
       <para></para>

@@ -2140,7 +1813,6 @@
   <glossent id="eviction">
 
     <gterm>eviction</gterm>
-
     <def>
 
       <para>

@@ -2150,7 +1822,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="lru" />
 
   </glossent>

@@ -2158,7 +1829,6 @@
   <glossent id="exclusive_lock">
 
     <gterm>exclusive lock</gterm>
-
     <def>
 
       <para>

@@ -2176,19 +1846,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="shared_lock" />
 
   </glossent>

@@ -2196,7 +1859,6 @@
   <glossent id="fixed_row_format">
 
     <gterm>fixed row format</gterm>
-
     <def>
 
       <para>

@@ -2210,9 +1872,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="compact_row_format" />
 
   </glossent>

@@ -2220,7 +1880,6 @@
   <glossent id="flush">
 
     <gterm>flush</gterm>
-
     <def>
 
       <para>

@@ -2231,7 +1890,6 @@
         <emphasis role="bold">undo log</emphasis>, and the
         <emphasis role="bold">buffer pool</emphasis>.
       </para>
-
       <para>
         Flushing can happen because a memory area becomes full and the
         system needs to free some space, because a

@@ -2242,13 +1900,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="redo_log" />
-
     <gseealso glosid="undo_log" />
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="commit" />
 
   </glossent>

@@ -2256,7 +1910,6 @@
   <glossent id="flush_list">
 
     <gterm>flush list</gterm>
-
     <def>
 
       <para>

@@ -2271,13 +1924,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="page" />
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="mini_transaction" />
-
     <gseealso glosid="mutex" />
 
   </glossent>

@@ -2285,7 +1934,6 @@
   <glossent id="foreign_key">
 
     <gterm>foreign key</gterm>
-
     <def>
 
       <para>

@@ -2294,7 +1942,6 @@
         both the <emphasis role="bold">parent table</emphasis> and the
         <emphasis role="bold">child table</emphasis>.
       </para>
-
       <para>
         In addition to enabling fast lookup of related information,
         foreign keys help to enforce referential integrity, by

@@ -2310,7 +1957,6 @@
         <emphasis role="bold">null</emphasis>, or automatically delete
         the corresponding rows in the other table.
       </para>
-
       <para>
         One of the stages in designing a
         <emphasis role="bold">normalized</emphasis> database is to

@@ -2321,19 +1967,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="parent_table" />
-
     <gseealso glosid="child_table" />
-
     <gseealso glosid="relational" />
-
     <gseealso glosid="foreign_key_constraint" />
-
     <gseealso glosid="null" />
-
     <gseealso glosid="normalized" />
-
     <gseealso glosid="join" />
 
   </glossent>

@@ -2341,7 +1980,6 @@
   <glossent id="foreign_key_constraint">
 
     <gterm>foreign key constraint</gterm>
-
     <def>
 
       <para>

@@ -2358,13 +1996,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="constraint" />
-
     <gseealso glosid="foreign_key" />
-
     <gseealso glosid="child_table" />
-
     <gseealso glosid="null" />
 
   </glossent>

@@ -2372,7 +2006,6 @@
   <glossent id="full_table_scan">
 
     <gterm>full table scan</gterm>
-
     <def>
 
       <para>

@@ -2385,7 +2018,6 @@
         have implications for the algorithms used in query optimization
         and managing the buffer pool.
       </para>
-
       <para>
         The purpose of <emphasis role="bold">indexes</emphasis> is to
         allow lookups for specific values or ranges of values within a

@@ -2393,11 +2025,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="lru" />
-
     <gseealso glosid="index" />
 
   </glossent>

@@ -2405,7 +2034,6 @@
   <glossent id="fast_index_creation">
 
     <gterm>fast index creation</gterm>
-
     <def>
 
       <para>

@@ -2414,7 +2042,6 @@
         completely rewrite the associated table. The speedup applies to
         dropping secondary indexes also.
       </para>
-
       <para>
         Because index maintenance can add performance overhead to many
         data transfer operations, consider doing operations such as

@@ -2422,7 +2049,6 @@
         <literal>INSERT INTO ... SELECT * FROM ...</literal> without any
         secondary indexes in place, and creating the indexes afterward.
       </para>
-
       <para>
         Even if you do not use the InnoDB Plugin as your primary storage
         engine, you can take advantage of this capability by enabling

@@ -2432,9 +2058,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="secondary_index" />
 
   </glossent>

@@ -2442,25 +2066,20 @@
   <glossent id="fast_shutdown">
 
     <gterm>fast shutdown</gterm>
-
     <def>
 
       <para>
         A shutdown procedure that is required before installation of the
         InnoDB Plugin. From the MySQL command line, issue the following
         command before performing the shutdown:
-
 <programlisting>SET GLOBAL innodb_fast_shutdown=0;</programlisting>
-
         To make this type of shutdown the default, specify by the
         configuration parameter
         <literal>innodb_fast_shutdown=0</literal>.
       </para>
 
     </def>
-
     <gseealso glosid="slow_shutdown" />
-
     <gseealso glosid="shutdown" />
 
   </glossent>

@@ -2468,14 +2087,12 @@
   <glossent id="frm_file">
 
     <gterm>.FRM file</gterm>
-
     <def>
 
       <para>
         The file containing the metadata, such as the table definition,
         of a MySQL table.
       </para>
-
       <para>
         For backups, you must always keep the full set of
         <literal>.FRM</literal> files along with the backup data, to be

@@ -2487,14 +2104,12 @@
         <emphasis role="bold">ibbackup </emphasis> command instead, you
         must copy the <literal>.FRM</literal> files yourself.
       </para>
-
       <para>
         Although each InnoDB table has a <literal>.FRM</literal> file,
         InnoDB maintains its own table metadata in the system
         tablespace; the <literal>.FRM</literal> files are not needed for
         InnoDB to operate on InnoDB tables.
       </para>
-
       <para>
         These files are backed up by the <emphasis role="bold">MySQL
         Enterprise Backup</emphasis> product. These files must not be

@@ -2509,11 +2124,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
-
     <gseealso glosid="ibbackup_command" />
 
   </glossent>

@@ -2521,7 +2133,6 @@
   <glossent id="file_format">
 
     <gterm>file format</gterm>
-
     <def>
 
       <para>

@@ -2531,13 +2142,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="antelope" />
-
     <gseealso glosid="barracuda" />
-
     <gseealso glosid="ibdata_file" />
-
     <gseealso glosid="row_format" />
 
   </glossent>

@@ -2545,7 +2152,6 @@
   <glossent id="file_per_table">
 
     <gterm>file-per-table</gterm>
-
     <def>
 
       <para>

@@ -2561,11 +2167,9 @@
         and the reclaimed space can be used by the operating system
         rather than remaining reserved for InnoDB.
       </para>
-
       <para>
         This mode is the default setting in MySQL 5.5.5 and higher.
       </para>
-
       <para>
         The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
         product is more flexible for tables that are in their own files.

@@ -2576,15 +2180,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="ibdata_file" />
-
     <gseealso glosid="innodb_file_per_table" />
-
     <gseealso glosid="file_format" />
-
     <gseealso glosid="row_format" />
 
   </glossent>

@@ -2592,7 +2191,6 @@
   <glossent id="ga">
 
     <gterm>GA</gterm>
-
     <def>
 
       <para>

@@ -2602,9 +2200,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="beta" />
-
     <gseealso glosid="early_adopter" />
 
   </glossent>

@@ -2612,7 +2208,6 @@
   <glossent id="gap">
 
     <gterm>gap</gterm>
-
     <def>
 
       <para>

@@ -2625,7 +2220,6 @@
         prevents another transaction from inserting a new value that is
         greater than 10.
       </para>
-
       <para>
         Gap locks are part of the tradeoff between performance and
         <emphasis role="bold">concurrency</emphasis>, and are used in

@@ -2634,15 +2228,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="supremum_record" />
-
     <gseealso glosid="infimum_record" />
 
   </glossent>

@@ -2650,7 +2239,6 @@
   <glossent id="group_commit">
 
     <gterm>group commit</gterm>
-
     <def>
 
       <para>

@@ -2662,13 +2250,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="plugin" />
-
     <gseealso glosid="xa" />
-
     <gseealso glosid="log_write" />
 
   </glossent>

@@ -2676,7 +2260,6 @@
   <glossent id="hash_index">
 
     <gterm>hash_index</gterm>
-
     <def>
 
       <para>

@@ -2688,7 +2271,6 @@
         for general-purpose queries, B-tree indexes are often a better
         choice.
       </para>
-
       <para>
         The InnoDB storage engine includes a variant of this index type,
         the <emphasis role="bold">adaptive hash index</emphasis>, that

@@ -2697,11 +2279,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="b_tree" />
-
     <gseealso glosid="adaptive_hash_index" />
 
   </glossent>

@@ -2709,7 +2288,6 @@
   <glossent id="heartbeat">
 
     <gterm>heartbeat</gterm>
-
     <def>
 
       <para>

@@ -2724,11 +2302,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="replication" />
-
     <gseealso glosid="master_database" />
-
     <gseealso glosid="slave_database" />
 
   </glossent>

@@ -2736,7 +2311,6 @@
   <glossent id="hot">
 
     <gterm>hot</gterm>
-
     <def>
 
       <para>

@@ -2745,7 +2319,6 @@
         locking or mutual exclusion, that it results in a performance or
         scalability issue.
       </para>
-
       <para>
         Although <quote>hot</quote> typically indicates an undesirable
         condition, a <emphasis role="bold">hot backup</emphasis> is the

@@ -2753,7 +2326,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
 
   </glossent>

@@ -2761,7 +2333,6 @@
   <glossent id="hot_backup">
 
     <gterm>hot backup</gterm>
-
     <def>
 
       <para>

@@ -2772,14 +2343,12 @@
         must exclude any data that was deleted while the backup was in
         process; and it must ignore any changes that were not committed.
       </para>
-
       <para>
         The Oracle product that performs hot backups, of InnoDB tables
         especially but also tables from MyISAM and other storage
         engines, is known as <emphasis role="bold">MySQL Enterprise
         Backup</emphasis>.
       </para>
-
       <para>
         The hot backup process consists of two stages. The initial
         copying of the data files produces a <emphasis role="bold">raw

@@ -2791,13 +2360,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="raw_backup" />
-
     <gseealso glosid="apply" />
-
     <gseealso glosid="prepared_backup" />
 
   </glossent>

@@ -2805,7 +2370,6 @@
   <glossent id="ibbackup_command">
 
     <gterm>ibbackup command</gterm>
-
     <def>
 
       <para>

@@ -2822,11 +2386,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -2834,7 +2395,6 @@
   <glossent id="ibbackup_logfile">
 
     <gterm>ibbackup_logfile</gterm>
-
     <def>
 
       <para>

@@ -2855,15 +2415,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="raw_backup" />
-
     <gseealso glosid="apply" />
-
     <gseealso glosid="prepared_backup" />
 
   </glossent>

@@ -2871,7 +2426,6 @@
   <glossent id="information_schema">
 
     <gterm>information schema</gterm>
-
     <def>
 
       <para>

@@ -2882,7 +2436,6 @@
         <literal>INFORMATION_SCHEMA.TABLES</literal> and
         <literal>INFORMATION_SCHEMA.COLUMNS</literal>.
       </para>
-
       <para>
         The InnoDB <emphasis role="bold">Plugin</emphasis> introduced
         some tables into the information schema that are specific to

@@ -2898,15 +2451,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="schema" />
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="compression" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -2914,7 +2462,6 @@
   <glossent id="innobackup_command">
 
     <gterm>innobackup command</gterm>
-
     <def>
 
       <para>

@@ -2929,11 +2476,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="ibbackup_command" />
 
   </glossent>

@@ -2941,7 +2485,6 @@
   <glossent id="innodb_autoinc_lock_mode">
 
     <gterm>innodb_autoinc_lock_mode</gterm>
-
     <def>
 
       <para>

@@ -2966,7 +2509,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="auto_increment_locking" />
 
   </glossent>

@@ -2974,7 +2516,6 @@
   <glossent id="innodb_strict_mode">
 
     <gterm>innodb_strict_mode</gterm>
-
     <def>
 
       <para>

@@ -2983,13 +2524,11 @@
         that are normally treated as warnings, cause errors instead (and
         the underlying statements fail).
       </para>
-
       <para>
         This mode is the default setting in MySQL 5.5.5 and higher.
       </para>
 
     </def>
-
     <gseealso glosid="strict_mode" />
 
   </glossent>

@@ -2997,7 +2536,6 @@
   <glossent id="innodb_hot_backup">
 
     <gterm>InnoDB Hot Backup</gterm>
-
     <def>
 
       <para>

@@ -3006,7 +2544,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
 
   </glossent>

@@ -3014,7 +2551,6 @@
   <glossent id="ib_logfile">
 
     <gterm>ib_logfile</gterm>
-
     <def>
 
       <para>

@@ -3025,16 +2561,13 @@
         statements are replayed automatically to correct data written by
         incomplete transactions, on startup following a crash.
       </para>
-
       <para>
         This data can not be used for manual recovery; for that type of
         operation, use the <emphasis role="bold">binary log</emphasis>.
       </para>
 
     </def>
-
     <gseealso glosid="redo_log" />
-
     <gseealso glosid="binary_log" />
 
   </glossent>

@@ -3042,7 +2575,6 @@
   <glossent id="ib_file_set">
 
     <gterm>ib-file set</gterm>
-
     <def>
 
       <para>

@@ -3057,9 +2589,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="database" />
-
     <gseealso glosid="schema" />
 
   </glossent>

@@ -3067,7 +2597,6 @@
   <glossent id="infimum_record">
 
     <gterm>infimum record</gterm>
-
     <def>
 
       <para>

@@ -3081,11 +2610,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="gap" />
-
     <gseealso glosid="supremum_record" />
-
     <gseealso glosid="pseudo_record" />
 
   </glossent>

@@ -3093,7 +2619,6 @@
   <glossent id="ibd_file">
 
     <gterm>ibd file</gterm>
-
     <def>
 
       <para>

@@ -3107,13 +2632,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="ibz_file" />
 
   </glossent>

@@ -3121,7 +2642,6 @@
   <glossent id="ibdata_file">
 
     <gterm>ibdata file</gterm>
-
     <def>
 
       <para>

@@ -3134,15 +2654,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="antelope" />
-
     <gseealso glosid="barracuda" />
-
     <gseealso glosid="file_format" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="system_tablespace" />
 
   </glossent>

@@ -3150,7 +2665,6 @@
   <glossent id="ibz_file">
 
     <gterm>ibz file</gterm>
-
     <def>
 
       <para>

@@ -3163,7 +2677,6 @@
         <literal>.ibd</literal> extension to a <literal>.ibz</literal>
         extension.
       </para>
-
       <para>
         The compression applied during backup is distinct from the
         <emphasis role="bold">compressed row format</emphasis> that

@@ -3175,17 +2688,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="ibd_file" />
-
     <gseealso glosid="compressed_backup" />
-
     <gseealso glosid="compressed_row_format" />
 
   </glossent>

@@ -3193,7 +2700,6 @@
   <glossent id="in_memory_database">
 
     <gterm>in-memory database</gterm>
-
     <def>
 
       <para>

@@ -3209,9 +2715,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="disk_based" />
-
     <gseealso glosid="acid" />
 
   </glossent>

@@ -3219,7 +2723,6 @@
   <glossent id="innodb_file_per_table">
 
     <gterm>innodb_file_per_table</gterm>
-
     <def>
 
       <para>

@@ -3232,18 +2735,14 @@
         named tables in <emphasis role="bold">MySQL Enterprise
         Backup</emphasis>.
       </para>
-
       <para>
         This option was once static, but can now be set using the
         <literal>SET GLOBAL</literal> command.
       </para>
 
     </def>
-
     <gseealso glosid="data_files" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="file_per_table" />
 
   </glossent>

@@ -3251,7 +2750,6 @@
   <glossent id="innodb_file_format">
 
     <gterm>innodb_file_format</gterm>
-
     <def>
 
       <para>

@@ -3265,19 +2763,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="file_format" />
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="antelope" />
-
     <gseealso glosid="barracuda" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="innodb_file_per_table" />
 
   </glossent>

@@ -3285,7 +2776,6 @@
   <glossent id="innodb_lock_wait_timeout">
 
     <gterm>innodb_lock_wait_timeout</gterm>
-
     <def>
 
       <para>

@@ -3297,11 +2787,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="victim" />
-
     <gseealso glosid="deadlock" />
-
     <gseealso glosid="deadlock_detection" />
 
   </glossent>

@@ -3309,13 +2796,11 @@
   <glossent id="innodb_table_locks">
 
     <gterm>innodb_table_locks</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -3323,13 +2808,11 @@
   <glossent id="innodb_locks_unsafe_for_binlog">
 
     <gterm>innodb_locks_unsafe_for_binlog</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -3337,13 +2820,11 @@
   <glossent id="implicit_row_lock">
 
     <gterm>implicit row lock</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -3351,7 +2832,6 @@
   <glossent id="incremental_backup">
 
     <gterm>incremental backup</gterm>
-
     <def>
 
       <para>

@@ -3366,7 +2846,6 @@
         backup up-to-date by applying each incremental backup to it,
         then perform a single restore operation.
       </para>
-
       <para>
         The granularity of changed data is at the
         <emphasis role="bold">page</emphasis> level. A page might

@@ -3375,11 +2854,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="page" />
 
   </glossent>

@@ -3387,7 +2863,6 @@
   <glossent id="index">
 
     <gterm>index</gterm>
-
     <def>
 
       <para>

@@ -3397,21 +2872,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="clustered_index" />
-
     <gseealso glosid="primary_key" />
-
     <gseealso glosid="secondary_index" />
-
     <gseealso glosid="b_tree" />
-
     <gseealso glosid="column_index" />
-
     <gseealso glosid="composite_index" />
-
     <gseealso glosid="covering_index" />
-
     <gseealso glosid="partial_index" />
 
   </glossent>

@@ -3419,7 +2886,6 @@
   <glossent id="index_prefix">
 
     <gterm>index prefix</gterm>
-
     <def>
 
       <para>

@@ -3432,9 +2898,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="composite_index" />
 
   </glossent>

@@ -3442,7 +2906,6 @@
   <glossent id="innodb">
 
     <gterm>InnoDB</gterm>
-
     <def>
 
       <para>

@@ -3455,13 +2918,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="storage_engine" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="hot_backup" />
 
   </glossent>

@@ -3469,7 +2928,6 @@
   <glossent id="insert">
 
     <gterm>insert</gterm>
-
     <def>
 
       <para>

@@ -3488,15 +2946,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="dml" />
-
     <gseealso glosid="insert_buffer" />
-
     <gseealso glosid="change_buffering" />
-
     <gseealso glosid="auto_increment" />
 
   </glossent>

@@ -3504,7 +2957,6 @@
   <glossent id="insert_buffer">
 
     <gterm>insert buffer</gterm>
-
     <def>
 
       <para>

@@ -3519,7 +2971,6 @@
         buffering</emphasis>, and <emphasis role="bold">purge
         buffering</emphasis>.
       </para>
-
       <para>
         Changes are only recorded in the insert buffer when the relevant
         page from the secondary index is not in the

@@ -3535,7 +2986,6 @@
         more efficiently than if each value were written to disk
         immediately.
       </para>
-
       <para>
         Physically, the insert buffer is part of the
         <emphasis role="bold">system tablespace</emphasis>, so that the

@@ -3543,28 +2993,19 @@
         changes are only applied when the pages are brought into the
         buffer pool due to some other read operation.
       </para>
-
       <para>
         To see information about the current data in the insert buffer,
         issue the <literal>SHOW INNODB STATUS</literal> command.
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="page" />
-
     <gseealso glosid="purge" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="change_buffering" />
-
     <gseealso glosid="insert_buffering" />
-
     <gseealso glosid="delete_buffering" />
-
     <gseealso glosid="purge_buffering" />
 
   </glossent>

@@ -3572,7 +3013,6 @@
   <glossent id="insert_buffering">
 
     <gterm>insert buffering</gterm>
-
     <def>
 
       <para>

@@ -3585,7 +3025,6 @@
         are <emphasis role="bold">delete buffering</emphasis> and
         <emphasis role="bold">purge buffering</emphasis>.
       </para>
-
       <para>
         Insert buffering is not used if the secondary index is unique,
         because the uniqueness of new values cannot be verified before

@@ -3594,13 +3033,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="change_buffering" />
-
     <gseealso glosid="insert_buffer" />
-
     <gseealso glosid="delete_buffering" />
-
     <gseealso glosid="purge_buffering" />
 
   </glossent>

@@ -3608,19 +3043,14 @@
   <glossent id="insert_intention_gap_lock">
 
     <gterm>insert-intention gap lock</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="intention_lock" />
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="gap" />
 
   </glossent>

@@ -3628,9 +3058,7 @@
   <glossent id="intention_exclusive_lock">
 
     <gterm>intention exclusive lock</gterm>
-
     <gsee glosid="intention_lock" />
-
 <!--
 <def>
 <para>

@@ -3648,7 +3076,6 @@
   <glossent id="intention_lock">
 
     <gterm>intention lock</gterm>
-
     <def>
 
       <para>

@@ -3668,17 +3095,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="lock_mode" />
-
     <gseealso glosid="lock" />
-
 <!-- <gseealso glosid="intention_exclusive_lock" /> -->
-
 <!-- <gseealso glosid="intention_shared_lock" /> -->
-
     <gseealso glosid="insert_intention_gap_lock" />
 
   </glossent>

@@ -3686,9 +3107,7 @@
   <glossent id="intention_shared_lock">
 
     <gterm>intention shared lock</gterm>
-
     <gsee glosid="intention_lock" />
-
 <!--
 <def>
 <para>

@@ -3705,7 +3124,6 @@
   <glossent id="isolation_level">
 
     <gterm>isolation level</gterm>
-
     <def>
 
       <para>

@@ -3717,7 +3135,6 @@
         multiple <emphasis role="bold">transactions</emphasis> are
         making changes and performing queries at the same time.
       </para>
-
       <para>
         From highest amount of consistency and protection to the least,
         the isolation levels supported by InnoDB are:

@@ -3726,7 +3143,6 @@
         <emphasis role="bold">consistent read</emphasis>, and
         <emphasis role="bold">read uncommitted</emphasis>.
       </para>
-
       <para>
         With the built-in InnoDB storage engine and the InnoDB Plugin,
         many users can keep the default isolation level

@@ -3743,17 +3159,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="serializable_read" />
-
     <gseealso glosid="read_uncommitted" />
 
   </glossent>

@@ -3761,7 +3171,6 @@
   <glossent id="join">
 
     <gterm>join</gterm>
-
     <def>
 
       <para>

@@ -3772,9 +3181,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="query" />
-
     <gseealso glosid="foreign_key" />
 
   </glossent>

@@ -3782,7 +3189,6 @@
   <glossent id="key_block_size">
 
     <gterm>key_block_size</gterm>
-
     <def>
 
       <para>

@@ -3794,7 +3200,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="compressed_row_format" />
 
   </glossent>

@@ -3802,7 +3207,6 @@
   <glossent id="logical_backup">
 
     <gterm>logical backup</gterm>
-
     <def>
 
       <para>

@@ -3816,9 +3220,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="backup" />
-
     <gseealso glosid="physical_backup" />
 
   </glossent>

@@ -3826,7 +3228,6 @@
   <glossent id="loose_">
 
     <gterm>loose_</gterm>
-
     <def>
 
       <para>

@@ -3848,7 +3249,6 @@
   <glossent id="list">
 
     <gterm>list</gterm>
-
     <def>
 
       <para>

@@ -3860,13 +3260,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="eviction" />
-
     <gseealso glosid="sublist" />
-
     <gseealso glosid="lru" />
 
   </glossent>

@@ -3874,7 +3270,6 @@
   <glossent id="lsn">
 
     <gterm>LSN</gterm>
-
     <def>
 
       <para>

@@ -3886,7 +3281,6 @@
         middle of one or more transactions.) It is used internally by
         InnoDB during crash recovery and for managing the buffer pool.
       </para>
-
       <para>
         In the <emphasis role="bold">MySQL Enterprise Backup</emphasis>
         product, you can specify an LSN to represent the point in time

@@ -3899,11 +3293,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="redo_log" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="incremental_backup" />
 
   </glossent>

@@ -3911,7 +3302,6 @@
   <glossent id="latch">
 
     <gterm>latch</gterm>
-
     <def>
 
       <para>

@@ -3930,17 +3320,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="mutex" />
-
     <gseealso glosid="rw_lock" />
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="performance_schema" />
 
   </glossent>

@@ -3948,7 +3332,6 @@
   <glossent id="lock">
 
     <gterm>lock</gterm>
-
     <def>
 
       <para>

@@ -3962,15 +3345,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="lock_mode" />
-
     <gseealso glosid="mutex" />
-
     <gseealso glosid="latch" />
-
     <gseealso glosid="pthreads" />
 
   </glossent>

@@ -3978,7 +3356,6 @@
   <glossent id="lock_escalation">
 
     <gterm>lock escalation</gterm>
-
     <def>
 
       <para>

@@ -3990,11 +3367,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="row_lock" />
-
     <gseealso glosid="table_lock" />
 
   </glossent>

@@ -4002,7 +3376,6 @@
   <glossent id="locking">
 
     <gterm>locking</gterm>
-
     <def>
 
       <para>

@@ -4021,19 +3394,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="mutex" />
-
     <gseealso glosid="latch" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="concurrency" />
 
   </glossent>

@@ -4041,7 +3407,6 @@
   <glossent id="lock_mode">
 
     <gterm>lock mode</gterm>
-
     <def>
 
       <para>

@@ -4049,13 +3414,11 @@
         transactions can acquire an S lock on that same row at the same
         time.
       </para>
-
       <para>
         An exclusive (X) lock allows a transaction to update or delete a
         row. No other transaction can acquire any kind of lock on that
         same row at the same time.
       </para>
-
       <para>
         <emphasis role="bold">Intention locks</emphasis> apply to the
         table level, and are used to indicate what kind of lock the

@@ -4072,11 +3435,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="intention_lock" />
 
   </glossent>

@@ -4084,17 +3444,13 @@
   <glossent id="lock_monitor">
 
     <gterm>lock monitor</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="deadlock" />
 
   </glossent>

@@ -4102,13 +3458,11 @@
   <glossent id="log_write">
 
     <gterm>log write</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="group_commit" />
 
   </glossent>

@@ -4116,7 +3470,6 @@
   <glossent id="lru">
 
     <gterm>LRU</gterm>
-
     <def>
 
       <para>

@@ -4134,9 +3487,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="eviction" />
 
   </glossent>

@@ -4144,7 +3495,6 @@
   <glossent id="master_database">
 
     <gterm>master database</gterm>
-
     <def>
 
       <para>

@@ -4156,9 +3506,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="replication" />
-
     <gseealso glosid="slave_database" />
 
   </glossent>

@@ -4166,13 +3514,11 @@
   <glossent id="master_thread">
 
     <gterm>master thread</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="thread" />
 
   </glossent>

@@ -4180,7 +3526,6 @@
   <glossent id="mrg_file">
 
     <gterm>.MRG file</gterm>
-
     <def>
 
       <para>

@@ -4192,9 +3537,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -4202,7 +3545,6 @@
   <glossent id="multiversion_concurrency_control">
 
     <gterm>multiversion concurrency control</gterm>
-
     <gsee glosid="mvcc" />
 
   </glossent>

@@ -4210,7 +3552,6 @@
   <glossent id="mvcc">
 
     <gterm>MVCC</gterm>
-
     <def>
 
       <para>

@@ -4226,7 +3567,6 @@
         <emphasis role="bold">locks</emphasis> held by the other
         transactions.
       </para>
-
       <para>
         This technique is not universal in the database world. Some
         other database products, and some other storage engines within

@@ -4234,15 +3574,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="concurrency" />
-
     <gseealso glosid="lock" />
 
   </glossent>

@@ -4250,7 +3585,6 @@
   <glossent id="mid_point_insertion_strategy">
 
     <gterm>mid-point insertion strategy</gterm>
-
     <def>
 
       <para>

@@ -4264,11 +3598,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="lru" />
-
     <gseealso glosid="full_table_scan" />
 
   </glossent>

@@ -4276,7 +3607,6 @@
   <glossent id="mysql">
 
     <gterm>mysql</gterm>
-
     <def>
 
       <para>

@@ -4287,7 +3617,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysqld" />
 
   </glossent>

@@ -4295,7 +3624,6 @@
   <glossent id="mysql_enterprise_backup">
 
     <gterm>MySQL Enterprise Backup</gterm>
-
     <def>
 
       <para>

@@ -4307,9 +3635,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="innodb" />
 
   </glossent>

@@ -4317,7 +3643,6 @@
   <glossent id="mysqld">
 
     <gterm>mysqld</gterm>
-
     <def>
 
       <para>

@@ -4328,7 +3653,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql" />
 
   </glossent>

@@ -4336,13 +3660,11 @@
   <glossent id="mysqldump">
 
     <gterm>mysqldump</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
 
   </glossent>

@@ -4350,13 +3672,11 @@
   <glossent id="monitor">
 
     <gterm>monitor</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="lock_monitor" />
 
   </glossent>

@@ -4364,7 +3684,6 @@
   <glossent id="myd_files">
 
     <gterm>.MYD files</gterm>
-
     <def>
 
       <para>

@@ -4376,11 +3695,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="myi_files" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -4388,7 +3704,6 @@
   <glossent id="myi_files">
 
     <gterm>.MYI files</gterm>
-
     <def>
 
       <para>

@@ -4400,11 +3715,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="myd_files" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -4412,7 +3724,6 @@
   <glossent id="mini_transaction">
 
     <gterm>mini-transaction</gterm>
-
     <def>
 
       <para>

@@ -4425,11 +3736,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="ddl" />
-
     <gseealso glosid="transaction" />
 
   </glossent>

@@ -4437,7 +3745,6 @@
   <glossent id="multi_core">
 
     <gterm>multi-core</gterm>
-
     <def>
 
       <para>

@@ -4452,7 +3759,6 @@
   <glossent id="my_cnf">
 
     <gterm>my.cnf</gterm>
-
     <def>
 
       <para>

@@ -4460,9 +3766,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="option_file" />
-
     <gseealso glosid="my_ini" />
 
   </glossent>

@@ -4470,7 +3774,6 @@
   <glossent id="my_ini">
 
     <gterm>my.ini</gterm>
-
     <def>
 
       <para>

@@ -4478,9 +3781,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="option_file" />
-
     <gseealso glosid="my_cnf" />
 
   </glossent>

@@ -4488,7 +3789,6 @@
   <glossent id="mutex">
 
     <gterm>mutex</gterm>
-
     <def>
 
       <para>

@@ -4505,15 +3805,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="pthreads" />
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="rw_lock" />
-
     <gseealso glosid="latch" />
-
     <gseealso glosid="performance_schema" />
 
   </glossent>

@@ -4521,7 +3816,6 @@
   <glossent id="non_blocking_io">
 
     <gterm>non-blocking I/O</gterm>
-
     <def>
 
       <para>

@@ -4530,7 +3824,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="asynchronous_io" />
 
   </glossent>

@@ -4538,7 +3831,6 @@
   <glossent id="non_repeatable_read">
 
     <gterm>non-repeatable read</gterm>
-
     <def>
 
       <para>

@@ -4547,14 +3839,12 @@
         data, but the queries return different results (changed by
         another transaction committing in the meantime).
       </para>
-
       <para>
         This kind of operation goes against the
         <emphasis role="bold">ACID</emphasis> principle of database
         design. Within a transaction, data should be consistent, with
         predictable and stable relationships.
       </para>
-
       <para>
         Among different <emphasis role="bold">isolation
         levels</emphasis>, non-repeatable reads are prevented by the

@@ -4565,21 +3855,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="serializable_read" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="read_uncommitted" />
-
     <gseealso glosid="acid" />
 
   </glossent>

@@ -4587,7 +3869,6 @@
   <glossent id="normalized">
 
     <gterm>normalized</gterm>
-
     <def>
 
       <para>

@@ -4596,7 +3877,6 @@
         ID, to avoid storing, querying, and updating redundant or
         lengthy values.
       </para>
-
       <para>
         For example, an address might be given a unique ID, so that a
         census database could represent the relationship

@@ -4605,7 +3885,6 @@
         storing multiple copies of a complex value such as
         <emphasis role="bold">123 Main Street, Anytown, USA</emphasis>.
       </para>
-
       <para>
         For another example, although a simple address book application
         might store each phone number in the same table as a person's

@@ -4614,7 +3893,6 @@
         table. This normalized representation could simplify large-scale
         updates when area codes split apart.
       </para>
-
       <para>
         Normalization is not always recommended. Data that is primarily
         queried, and only updated by deleting entirely and reloading, is

@@ -4625,9 +3903,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="relational" />
-
     <gseealso glosid="foreign_key" />
 
   </glossent>

@@ -4635,7 +3911,6 @@
   <glossent id="null">
 
     <gterm>NULL</gterm>
-
     <def>
 
       <para>

@@ -4651,7 +3926,6 @@
         <literal>NULL</literal> values uses the SQL idioms <literal>IS
         NULL</literal> or <literal>IS NOT NULL</literal>.
       </para>
-
       <para>
         <literal>NULL</literal> values play a part in index operations,
         because for performance a database must minimize the overhead of

@@ -4667,7 +3941,6 @@
         index, allowing for better query optimization (accurate counting
         of rows and estimation of whether to use the index).
       </para>
-
       <para>
         Because the <emphasis role="bold">primary key</emphasis> must be
         able to uniquely identify every row in the table, a

@@ -4676,7 +3949,6 @@
         cannot contain any rows with <literal>NULL</literal> values in
         all columns.
       </para>
-
       <para>
         Although the Oracle database allows a <literal>NULL</literal>
         value to be concatenated with a string, InnoDB treats the result

@@ -4684,11 +3956,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="index" />
-
     <gseealso glosid="primary_key" />
 
   </glossent>

@@ -4696,7 +3965,6 @@
   <glossent id="off_page_column">
 
     <gterm>off-page column</gterm>
-
     <def>
 
       <para>

@@ -4708,9 +3976,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="overflow_page" />
-
     <gseealso glosid="b_tree" />
 
   </glossent>

@@ -4718,7 +3984,6 @@
   <glossent id="oltp">
 
     <gterm>OLTP</gterm>
-
     <def>
 
       <para>

@@ -4736,13 +4001,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="dml" />
-
     <gseealso glosid="query" />
-
     <gseealso glosid="data_warehouse" />
 
   </glossent>

@@ -4750,7 +4011,6 @@
   <glossent id="opt_file">
 
     <gterm>.OPT file</gterm>
-
     <def>
 
       <para>

@@ -4762,9 +4022,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -4772,7 +4030,6 @@
   <glossent id="optimistic">
 
     <gterm>optimistic</gterm>
-
     <def>
 
       <para>

@@ -4790,7 +4047,6 @@
         does little unnecessary work; when requests do fail, extra work
         must be done to clean up and undo changes.
       </para>
-
       <para>
         InnoDB uses optimistic strategies for operations such as
         <emphasis role="bold">locking</emphasis> and

@@ -4800,7 +4056,6 @@
         requiring more work to undo the changes if the transaction is
         rolled back.
       </para>
-
       <para>
         The opposite of an optimistic strategy is a
         <emphasis role="bold">pessimistic</emphasis> one, where a system

@@ -4811,11 +4066,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="pessimistic" />
 
   </glossent>

@@ -4823,13 +4075,11 @@
   <glossent id="option">
 
     <gterm>option</gterm>
-
     <def>
 
       <para>
         A configuration parameter for MySQL.
       </para>
-
       <para>
         In the context of the InnoDB storage engine (either the built-in
         InnoDB or the InnoDB Plugin), each option name starts with the

@@ -4837,11 +4087,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="option_file" />
-
     <gseealso glosid="built_in" />
-
     <gseealso glosid="plugin" />
 
   </glossent>

@@ -4849,7 +4096,6 @@
   <glossent id="option_file">
 
     <gterm>option file</gterm>
-
     <def>
 
       <para>

@@ -4859,9 +4105,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="configuration_file" />
-
     <gseealso glosid="my_cnf" />
 
   </glossent>

@@ -4869,7 +4113,6 @@
   <glossent id="overflow_page">
 
     <gterm>overflow page</gterm>
-
     <def>
 
       <para>

@@ -4882,11 +4125,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="page" />
-
     <gseealso glosid="b_tree" />
-
     <gseealso glosid="off_page_column" />
 
   </glossent>

@@ -4894,7 +4134,6 @@
   <glossent id="parent_table">
 
     <gterm>parent table</gterm>
-
     <def>
 
       <para>

@@ -4911,9 +4150,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="foreign_key" />
-
     <gseealso glosid="child_table" />
 
   </glossent>

@@ -4921,7 +4158,6 @@
   <glossent id="partial_index">
 
     <gterm>partial index</gterm>
-
     <def>
 
       <para>

@@ -4932,9 +4168,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="index_prefix" />
 
   </glossent>

@@ -4942,7 +4176,6 @@
   <glossent id="par_file">
 
     <gterm>.PAR file</gterm>
-
     <def>
 
       <para>

@@ -4954,9 +4187,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -4964,22 +4195,18 @@
   <glossent id="performance_schema">
 
     <gterm>Performance Schema</gterm>
-
     <def>
 
       <para>
-        The <literal>PERFORMANCE_SCHEMA</literal> schema, in MySQL 5.5
+        The <literal>performance_schema</literal> schema, in MySQL 5.5
         and up, presents a set of tables that you can query to get
         detailed information about the performance characteristics of
         many internal parts of the MySQL server.
       </para>
 
     </def>
-
     <gseealso glosid="latch" />
-
     <gseealso glosid="rw_lock" />
-
     <gseealso glosid="mutex" />
 
   </glossent>

@@ -4987,7 +4214,6 @@
   <glossent id="pessimistic">
 
     <gterm>pessimistic</gterm>
-
     <def>
 
       <para>

@@ -5002,18 +4228,14 @@
         strategy of acquiring all locks needed by a transaction at the
         very beginning.
       </para>
-
       <para>
         Many built-in database mechanisms use the opposite
         <emphasis role="bold">optimistic</emphasis> methodology.
       </para>
 
     </def>
-
     <gseealso glosid="optimistic" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="deadlock" />
 
   </glossent>

@@ -5021,7 +4243,6 @@
   <glossent id="physical_backup">
 
     <gterm>physical backup</gterm>
-
     <def>
 
       <para>

@@ -5034,11 +4255,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="logical_backup" />
 
   </glossent>

@@ -5046,7 +4264,6 @@
   <glossent id="pitr">
 
     <gterm>PITR backup</gterm>
-
     <def>
 
       <para>

@@ -5055,7 +4272,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="point_in_time_recovery" />
 
   </glossent>

@@ -5063,7 +4279,6 @@
   <glossent id="point_in_time_recovery">
 
     <gterm>point-in-time recovery</gterm>
-
     <def>
 
       <para>

@@ -5083,15 +4298,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="logical_backup" />
-
     <gseealso glosid="physical_backup" />
-
     <gseealso glosid="pitr" />
 
   </glossent>

@@ -5099,7 +4309,6 @@
   <glossent id="prepared_backup">
 
     <gterm>prepared backup</gterm>
-
     <def>
 
       <para>

@@ -5115,17 +4324,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="binary_log" />
-
     <gseealso glosid="incremental_backup" />
-
     <gseealso glosid="restore" />
-
     <gseealso glosid="raw_backup" />
 
   </glossent>

@@ -5133,7 +4336,6 @@
   <glossent id="primary_key">
 
     <gterm>primary key</gterm>
-
     <def>
 
       <para>

@@ -5142,7 +4344,6 @@
         table. As such, it must be a unique index that does not contain
         any <literal>NULL</literal> values.
       </para>
-
       <para>
         InnoDB requires that every table has such an index (also called
         the <emphasis role="bold">clustered index</emphasis> or

@@ -5151,9 +4352,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="clustered_index" />
-
     <gseealso glosid="index" />
 
   </glossent>

@@ -5161,7 +4360,6 @@
   <glossent id="pthreads">
 
     <gterm>Pthreads</gterm>
-
     <def>
 
       <para>

@@ -5172,7 +4370,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="mutex" />
 
   </glossent>

@@ -5180,7 +4377,6 @@
   <glossent id="page">
 
     <gterm>page</gterm>
-
     <def>
 
       <para>

@@ -5193,20 +4389,15 @@
         structures so that the information about the row can be stored
         in one page.
       </para>
-
       <para>
         One way to fit more data in each page is to use
         <emphasis role="bold">compressed row format</emphasis>.
       </para>
 
     </def>
-
     <gseealso glosid="data_files" />
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="page_size" />
-
     <gseealso glosid="compressed_row_format" />
 
   </glossent>

@@ -5214,7 +4405,6 @@
   <glossent id="page_size">
 
     <gterm>page size</gterm>
-
     <def>
 
       <para>

@@ -5226,7 +4416,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="page" />
 
   </glossent>

@@ -5234,7 +4423,6 @@
   <glossent id="plugin">
 
     <gterm>plugin</gterm>
-
     <def>
 
       <para>

@@ -5250,7 +4438,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="built_in" />
 
   </glossent>

@@ -5258,13 +4445,11 @@
   <glossent id="predicate_locking">
 
     <gterm>predicate locking</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -5272,7 +4457,6 @@
   <glossent id="pseudo_record">
 
     <gterm>pseudo-record</gterm>
-
     <def>
 
       <para>

@@ -5282,11 +4466,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="supremum_record" />
-
     <gseealso glosid="infimum_record" />
 
   </glossent>

@@ -5294,7 +4475,6 @@
   <glossent id="purge">
 
     <gterm>purge</gterm>
-
     <def>
 
       <para>

@@ -5306,11 +4486,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="delete" />
-
     <gseealso glosid="crash_recovery" />
-
     <gseealso glosid="doublewrite_buffer" />
 
   </glossent>

@@ -5318,7 +4495,6 @@
   <glossent id="purge_buffering">
 
     <gterm>purge buffering</gterm>
-
     <def>
 
       <para>

@@ -5336,13 +4512,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="change_buffering" />
-
     <gseealso glosid="insert_buffer" />
-
     <gseealso glosid="insert_buffering" />
-
     <gseealso glosid="delete_buffering" />
 
   </glossent>

@@ -5350,7 +4522,6 @@
   <glossent id="purge_thread">
 
     <gterm>purge thread</gterm>
-
     <def>
 
       <para>

@@ -5360,9 +4531,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="thread" />
-
     <gseealso glosid="purge" />
 
   </glossent>

@@ -5370,7 +4539,6 @@
   <glossent id="phantom">
 
     <gterm>phantom</gterm>
-
     <def>
 
       <para>

@@ -5381,7 +4549,6 @@
         so that it matches the <literal>WHERE</literal> clause of the
         query.
       </para>
-
       <para>
         This occurrence is known as a phantom read. It is harder to
         guard against than a <emphasis role="bold">non-repeatable

@@ -5389,7 +4556,6 @@
         query result set does not prevent the changes that cause the
         phantom to appear.
       </para>
-
       <para>
         Among different <emphasis role="bold">isolation
         levels</emphasis>, phantom reads are prevented by the

@@ -5400,19 +4566,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="serializable_read" />
-
     <gseealso glosid="non_repeatable_read" />
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="read_uncommitted" />
 
   </glossent>

@@ -5420,7 +4579,6 @@
   <glossent id="prefix">
 
     <gterm>prefix</gterm>
-
     <gsee glosid="index_prefix" />
 
   </glossent>

@@ -5428,7 +4586,6 @@
   <glossent id="query">
 
     <gterm>query</gterm>
-
     <def>
 
       <para>

@@ -5439,20 +4596,15 @@
         might be optimized by consulting an
         <emphasis role="bold">index</emphasis>.
       </para>
-
       <para>
         Normally with MySQL, queries are coded using SQL. (Even if you
         are using some other language for the main application logic.)
       </para>
 
     </def>
-
     <gseealso glosid="table" />
-
     <gseealso glosid="database" />
-
     <gseealso glosid="index" />
-
     <gseealso glosid="sql" />
 
   </glossent>

@@ -5460,7 +4612,6 @@
   <glossent id="raid">
 
     <gterm>RAID</gterm>
-
     <def>
 
       <para>

@@ -5472,7 +4623,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="concurrency" />
 
   </glossent>

@@ -5480,7 +4630,6 @@
   <glossent id="raw_backup">
 
     <gterm>raw backup</gterm>
-
     <def>
 
       <para>

@@ -5496,19 +4645,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="binary_log" />
-
     <gseealso glosid="ibbackup_logfile" />
-
     <gseealso glosid="incremental_backup" />
-
     <gseealso glosid="restore" />
-
     <gseealso glosid="prepared_backup" />
 
   </glossent>

@@ -5516,7 +4658,6 @@
   <glossent id="read_ahead">
 
     <gterm>read-ahead</gterm>
-
     <def>
 
       <para>

@@ -5526,7 +4667,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_cache" />
 
   </glossent>

@@ -5534,7 +4674,6 @@
   <glossent id="redo_log">
 
     <gterm>redo log</gterm>
-
     <def>
 
       <para>

@@ -5546,7 +4685,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="ib_logfile" />
 
   </glossent>

@@ -5554,7 +4692,6 @@
   <glossent id="redundant_row_format">
 
     <gterm>redundant row format</gterm>
-
     <def>
 
       <para>

@@ -5565,9 +4702,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="row_format" />
-
     <gseealso glosid="compact_row_format" />
 
   </glossent>

@@ -5575,13 +4710,11 @@
   <glossent id="relational">
 
     <gterm>relational</gterm>
-
     <def>
 
       <para>
         An important aspect of modern database systems.
       </para>
-
       <para>
         In a mathematical context, the relations within a database are
         derived from set theory. For example, the <literal>OR</literal>

@@ -5589,7 +4722,6 @@
         <literal>WHERE</literal> clause represent the notions of union
         and intersection.
       </para>
-
       <para>
         In everyday terms, the database encodes and enforces
         relationships such as one-to-one, one-to-many, many-to-one, and

@@ -5600,7 +4732,6 @@
         taxpayer ID, and any taxpayer ID could only be associated with
         one person.
       </para>
-
       <para>
         At the database level, these relationships are expressed through
         SQL features such as columns within a table, unique and

@@ -5613,11 +4744,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="foreign_key" />
-
     <gseealso glosid="normalized" />
 
   </glossent>

@@ -5625,7 +4753,6 @@
   <glossent id="restore">
 
     <gterm>restore</gterm>
-
     <def>
 
       <para>

@@ -5642,17 +4769,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="prepared_backup" />
-
     <gseealso glosid="replication" />
-
     <gseealso glosid="slave_database" />
-
     <gseealso glosid="innobackup_command" />
 
   </glossent>

@@ -5660,7 +4781,6 @@
   <glossent id="row_format">
 
     <gterm>row format</gterm>
-
     <def>
 
       <para>

@@ -5669,7 +4789,6 @@
         formats are introduced to support the resulting improvements in
         storage efficiency and performance.
       </para>
-
       <para>
         Each table has its own row format, specified through the
         <literal>ROW_FORMAT</literal> option. To see the row format for

@@ -5682,15 +4801,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="fixed_row_format" />
-
     <gseealso glosid="dynamic_row_format" />
-
     <gseealso glosid="compact_row_format" />
-
     <gseealso glosid="redundant_row_format" />
-
     <gseealso glosid="compressed_row_format" />
 
   </glossent>

@@ -5698,7 +4812,6 @@
   <glossent id="random_dive">
 
     <gterm>random dive</gterm>
-
     <def>
 
       <para>

@@ -5708,13 +4821,11 @@
         the number of different values. This operation occurs when each
         table is first opened.
       </para>
-
       <para>
         Originally, the number of sampled pages was fixed at 8; now, it
         is determined by the setting of the
         <literal>innodb_stats_sample_pages</literal> parameter.
       </para>
-
       <para>
         The way the random pages are picked depends on the setting of
         the innodb_use_legacy_cardinality_algorithm parameter. The

@@ -5723,7 +4834,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="cardinality" />
 
   </glossent>

@@ -5731,7 +4841,6 @@
   <glossent id="referential_integrity">
 
     <gterm>referential integrity</gterm>
-
     <def>
 
       <para>

@@ -5744,9 +4853,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="foreign_key" />
 
   </glossent>

@@ -5754,7 +4861,6 @@
   <glossent id="row_based_replication">
 
     <gterm>row-based replication</gterm>
-
     <def>
 
       <para>

@@ -5765,13 +4871,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="replication" />
-
     <gseealso glosid="statement_based_replication" />
-
     <gseealso glosid="auto_increment_locking" />
-
     <gseealso glosid="innodb_autoinc_lock_mode" />
 
   </glossent>

@@ -5779,7 +4881,6 @@
   <glossent id="read_uncommitted">
 
     <gterm>read uncommitted</gterm>
-
     <def>
 
       <para>

@@ -5799,15 +4900,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="dirty_read" />
 
   </glossent>

@@ -5815,7 +4911,6 @@
   <glossent id="read_committed">
 
     <gterm>read committed</gterm>
-
     <def>
 
       <para>

@@ -5828,7 +4923,6 @@
         bad data, but the data that it does see may depend to some
         extent on the timing of other transactions.
       </para>
-
       <para>
         When a transaction with this isolation level performs
         <literal>UPDATE ... WHERE</literal> or <literal>DELETE ...

@@ -5839,17 +4933,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="serializable_read" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
 
   </glossent>

@@ -5857,7 +4945,6 @@
   <glossent id="repeatable_read">
 
     <gterm>repeatable read</gterm>
-
     <def>
 
       <para>

@@ -5871,7 +4958,6 @@
         the same snapshot, that is, the data as it was at the time the
         transaction started.
       </para>
-
       <para>
         When a transaction with this isolation level performs
         <literal>UPDATE ... WHERE</literal>, <literal>DELETE ...

@@ -5881,17 +4967,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="serializable_read" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
 
   </glossent>

@@ -5899,13 +4979,11 @@
   <glossent id="record_only_lock">
 
     <gterm>record-only lock</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="locking" />
 
   </glossent>

@@ -5913,7 +4991,6 @@
   <glossent id="replication">
 
     <gterm>replication</gterm>
-
     <def>
 
       <para>

@@ -5930,13 +5007,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="master_database" />
-
     <gseealso glosid="slave_database" />
-
     <gseealso glosid="row_based_replication" />
-
     <gseealso glosid="statement_based_replication" />
 
   </glossent>

@@ -5944,7 +5017,6 @@
   <glossent id="rollback">
 
     <gterm>rollback</gterm>
-
     <def>
 
       <para>

@@ -5954,7 +5026,6 @@
         <emphasis role="bold">commit</emphasis>, which makes permanent
         any changes made in the transaction.
       </para>
-
       <para>
         By default, MySQL uses the
         <emphasis role="bold">autocommit</emphasis> setting, which

@@ -5964,11 +5035,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="transaction" />
 
   </glossent>

@@ -5976,7 +5044,6 @@
   <glossent id="rollback_segment">
 
     <gterm>rollback segment</gterm>
-
     <def>
 
       <para>

@@ -5986,9 +5053,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="undo_log" />
-
     <gseealso glosid="system_tablespace" />
 
   </glossent>

@@ -5996,7 +5061,6 @@
   <glossent id="row_lock">
 
     <gterm>row lock</gterm>
-
     <def>
 
       <para>

@@ -6006,11 +5070,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="lock_mode" />
-
     <gseealso glosid="transaction" />
 
   </glossent>

@@ -6018,7 +5079,6 @@
   <glossent id="rw_lock">
 
     <gterm>rw-lock</gterm>
-
     <def>
 
       <para>

@@ -6033,13 +5093,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="latch" />
-
     <gseealso glosid="performance_schema" />
-
     <gseealso glosid="mutex" />
 
   </glossent>

@@ -6047,7 +5103,6 @@
   <glossent id="savepoint">
 
     <gterm>savepoint</gterm>
-
     <def>
 
       <para>

@@ -6063,9 +5118,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="rollback" />
 
   </glossent>

@@ -6073,7 +5126,6 @@
   <glossent id="secondary_index">
 
     <gterm>secondary index</gterm>
-
     <def>
 
       <para>

@@ -6084,7 +5136,6 @@
         required for each InnoDB table, and stores the data for all the
         table columns.)
       </para>
-
       <para>
         A secondary index can be used to satisfy queries that only
         require values from the indexed columns. For more complex

@@ -6092,7 +5143,6 @@
         table, which are then retrieved through lookups using the
         clustered index.
       </para>
-
       <para>
         Creating and dropping secondary indexes has traditionally
         involved significant overhead from copying all the data in the

@@ -6104,11 +5154,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="index" />
-
     <gseealso glosid="clustered_index" />
-
     <gseealso glosid="fast_index_creation" />
 
   </glossent>

@@ -6116,7 +5163,6 @@
   <glossent id="schema">
 
     <gterm>schema</gterm>
-
     <def>
 
       <para>

@@ -6128,14 +5174,12 @@
         Ideally, they are also connected logically, working together as
         part of a unified application or flexible framework.
       </para>
-
       <para>
         In MySQL, physically, a <emphasis role="bold">schema</emphasis>
         is analogous to a <emphasis role="bold">database</emphasis>.
         Typically, all the objects for a MySQL application are contained
         within a single database.
       </para>
-
       <para>
         Some other database products draw a distinction. For example, in
         the Oracle Database product, a

@@ -6145,11 +5189,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="database" />
-
     <gseealso glosid="information_schema" />
-
     <gseealso glosid="ib_file_set" />
 
   </glossent>

@@ -6157,7 +5198,6 @@
   <glossent id="semi_consistent_read">
 
     <gterm>semi-consistent read</gterm>
-
     <def>
 
       <para>

@@ -6178,11 +5218,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="read_committed" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="isolation_level" />
 
   </glossent>

@@ -6190,7 +5227,6 @@
   <glossent id="server">
 
     <gterm>server</gterm>
-
     <def>
 
       <para>

@@ -6204,9 +5240,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="client" />
-
     <gseealso glosid="mysqld" />
 
   </glossent>

@@ -6214,7 +5248,6 @@
   <glossent id="selectivity">
 
     <gterm>selectivity</gterm>
-
     <def>
 
       <para>

@@ -6229,7 +5262,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="cardinality" />
 
   </glossent>

@@ -6237,7 +5269,6 @@
   <glossent id="shared_tablespace">
 
     <gterm>shared tablespace</gterm>
-
     <def>
 
       <para>

@@ -6246,7 +5277,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="system_tablespace" />
 
   </glossent>

@@ -6254,7 +5284,6 @@
   <glossent id="strict_mode">
 
     <gterm>strict mode</gterm>
-
     <def>
 
       <para>

@@ -6268,13 +5297,11 @@
         with default values, now cause the <literal>CREATE
         TABLE</literal> operation to fail.
       </para>
-
       <para>
         MySQL also has something called strict mode.
       </para>
 
     </def>
-
     <gseealso glosid="innodb_strict_mode" />
 
   </glossent>

@@ -6282,7 +5309,6 @@
   <glossent id="shutdown">
 
     <gterm>shutdown</gterm>
-
     <def>
 
       <para>

@@ -6293,16 +5319,13 @@
         <emphasis role="bold">fast</emphasis> to shut down but must do
         the cleanup the next time it starts.
       </para>
-
       <para>
         The shutdown mode is controlled by the
         <literal>innodb_fast_shutdown</literal> option.
       </para>
 
     </def>
-
     <gseealso glosid="slow_shutdown" />
-
     <gseealso glosid="fast_shutdown" />
 
   </glossent>

@@ -6310,19 +5333,15 @@
   <glossent id="slow_shutdown">
 
     <gterm>slow shutdown</gterm>
-
     <def>
 
       <para>
         A type of shutdown that does additional flushing operations
         before completing. Specified by the configuration parameter
         <literal>innodb_fast_shutdown=0</literal>.
-
 <!-- <programlisting>SET GLOBAL innodb_fast_shutdown=0;</programlisting> -->
-
         Although the shutdown itself can take longer, that time will be
         saved on the subsequent startup.
-
 <!--
 Referenced in installation section of Plugin doc,
 but command or parameters not shown on first use.

@@ -6333,9 +5352,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="shutdown" />
-
     <gseealso glosid="fast_shutdown" />
 
   </glossent>

@@ -6343,7 +5360,6 @@
   <glossent id="sublist">
 
     <gterm>sublist</gterm>
-
     <def>
 
       <para>

@@ -6355,13 +5371,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
-
     <gseealso glosid="eviction" />
-
     <gseealso glosid="list" />
-
     <gseealso glosid="lru" />
 
   </glossent>

@@ -6369,7 +5381,6 @@
   <glossent id="storage_engine">
 
     <gterm>storage engine</gterm>
-
     <def>
 
       <para>

@@ -6381,7 +5392,6 @@
         usage, read speed versus write speed, and speed versus
         robustness.
       </para>
-
       <para>
         The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
         product is optimized for backing up tables produced by the

@@ -6391,9 +5401,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="innodb" />
-
     <gseealso glosid="mysql_enterprise_backup" />
 
   </glossent>

@@ -6401,7 +5409,6 @@
   <glossent id="scalability">
 
     <gterm>scalability</gterm>
-
     <def>
 
       <para>

@@ -6424,7 +5431,6 @@
   <glossent id="statement_based_replication">
 
     <gterm>statement-based replication</gterm>
-
     <def>
 
       <para>

@@ -6436,13 +5442,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="replication" />
-
     <gseealso glosid="auto_increment_locking" />
-
     <gseealso glosid="innodb_autoinc_lock_mode" />
-
     <gseealso glosid="row_based_replication" />
 
   </glossent>

@@ -6450,7 +5452,6 @@
   <glossent id="serializable_read">
 
     <gterm>serializable read</gterm>
-
     <def>
 
       <para>

@@ -6464,7 +5465,6 @@
         start of the current transaction, cause the current transaction
         to wait.
       </para>
-
       <para>
         This is the default isolation level specified by the SQL
         standard. In practice, this degree of strictness is rarely

@@ -6473,17 +5473,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="repeatable_read" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="isolation_level" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="acid" />
 
   </glossent>

@@ -6491,7 +5485,6 @@
   <glossent id="supremum_record">
 
     <gterm>supremum record</gterm>
-
     <def>
 
       <para>

@@ -6505,11 +5498,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="gap" />
-
     <gseealso glosid="infimum_record" />
-
     <gseealso glosid="pseudo_record" />
 
   </glossent>

@@ -6517,7 +5507,6 @@
   <glossent id="shared_lock">
 
     <gterm>shared lock</gterm>
-
     <def>
 
       <para>

@@ -6529,11 +5518,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="exclusive_lock" />
 
   </glossent>

@@ -6541,7 +5527,6 @@
   <glossent id="slave_database">
 
     <gterm>slave database</gterm>
-
     <def>
 
       <para>

@@ -6553,7 +5538,6 @@
         those same changes. Thus it maintains the same contents as the
         master, although it might lag somewhat behind.
       </para>
-
       <para>
         In MySQL, slave databases are commonly used in disaster
         recovery, to take the place of a master database that fails.

@@ -6563,9 +5547,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="replication" />
-
     <gseealso glosid="master_database" />
 
   </glossent>

@@ -6573,7 +5555,6 @@
   <glossent id="__sleep">
 
     <gterm>--sleep</gterm>
-
     <def>
 
       <para>

@@ -6589,13 +5570,11 @@
   <glossent id="space_id">
 
     <gterm>space ID</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="tablespace" />
 
   </glossent>

@@ -6603,7 +5582,6 @@
   <glossent id="sql">
 
     <gterm>SQL</gterm>
-
     <def>
 
       <para>

@@ -6615,11 +5593,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="ddl" />
-
     <gseealso glosid="dml" />
-
     <gseealso glosid="query" />
 
   </glossent>

@@ -6627,7 +5602,6 @@
   <glossent id="stored_procedure">
 
     <gterm>stored procedure</gterm>
-
     <def>
 
       <para></para>

@@ -6639,7 +5613,6 @@
   <glossent id="system_tablespace">
 
     <gterm>system tablespace</gterm>
-
     <def>
 
       <para>

@@ -6647,7 +5620,6 @@
         a database, as well as all the metadata for InnoDB-related
         objects (the <emphasis role="bold">data dictionary</emphasis>).
       </para>
-
       <para>
         Turning on the
         <emphasis role="bold">innodb_file_per_table</emphasis> option

@@ -6655,7 +5627,6 @@
         <emphasis role="bold">tablespace</emphasis>, reducing the size
         of, and dependencies on, the system tablespace.
       </para>
-
       <para>
         Keeping all table data in the system tablespace has implications
         for the <emphasis role="bold">MySQL Enterprise Backup</emphasis>

@@ -6666,19 +5637,12 @@
       </para>
 
     </def>
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="innodb_file_per_table" />
-
     <gseealso glosid="ibdata_file" />
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="file_format" />
-
     <gseealso glosid="barracuda" />
 
   </glossent>

@@ -6686,7 +5650,6 @@
   <glossent id="table">
 
     <gterm>table</gterm>
-
     <def>
 
       <para>

@@ -6698,13 +5661,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="clustered_index" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="table" />
-
     <gseealso glosid="system_tablespace" />
 
   </glossent>

@@ -6712,7 +5671,6 @@
   <glossent id="table_lock">
 
     <gterm>table lock</gterm>
-
     <def>
 
       <para>

@@ -6731,21 +5689,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="table" />
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="locking" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="row_lock" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="dml" />
-
     <gseealso glosid="query" />
 
   </glossent>

@@ -6753,7 +5703,6 @@
   <glossent id="tablespace">
 
     <gterm>tablespace</gterm>
-
     <def>
 
       <para>

@@ -6765,7 +5714,6 @@
         option allows newly created tables to each have their own
         tablespace, with a separate data file for each table.
       </para>
-
       <para>
         Tablespaces created by the built-in InnoDB storage engine are
         upward compatible with the InnoDB Plugin. Tablespaces created by

@@ -6775,21 +5723,13 @@
       </para>
 
     </def>
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="innodb_file_per_table" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="ibdata_file" />
-
     <gseealso glosid="antelope" />
-
     <gseealso glosid="barracuda" />
-
     <gseealso glosid="compressed_row_format" />
 
   </glossent>

@@ -6797,7 +5737,6 @@
   <glossent id="tablespace_dictionary">
 
     <gterm>tablespace dictionary</gterm>
-
     <def>
 
       <para>

@@ -6815,17 +5754,11 @@
       </para>
 
     </def>
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="data_dictionary" />
-
     <gseealso glosid="frm_file" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="ibd_file" />
-
     <gseealso glosid="file_per_table" />
 
   </glossent>

@@ -6833,7 +5766,6 @@
   <glossent id="temporary_table">
 
     <gterm>temporary table</gterm>
-
     <def>
 
       <para>

@@ -6846,7 +5778,6 @@
         tables, by being less scrupulous about writing data to disk and
         other measures to protect the data across restarts.
       </para>
-
       <para>
         Sometimes, the data itself is removed automatically at a set
         time, such as when the transaction ends or when the session

@@ -6855,7 +5786,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="table" />
 
   </glossent>

@@ -6863,15 +5793,12 @@
   <glossent id="thread">
 
     <gterm>thread</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="master_thread" />
-
     <gseealso glosid="pthreads" />
 
   </glossent>

@@ -6879,13 +5806,11 @@
   <glossent id="table_monitor">
 
     <gterm>table monitor</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="monitor" />
 
   </glossent>

@@ -6893,13 +5818,11 @@
   <glossent id="tablespace_monitor">
 
     <gterm>tablespace monitor</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="monitor" />
 
   </glossent>

@@ -6907,13 +5830,11 @@
   <glossent id="trigger">
 
     <gterm>trigger</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="stored_procedure" />
 
   </glossent>

@@ -6921,7 +5842,6 @@
   <glossent id="trg_file">
 
     <gterm>.TRG file</gterm>
-
     <def>
 
       <para>

@@ -6933,11 +5853,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
-
     <gseealso glosid="trn_file" />
 
   </glossent>

@@ -6945,7 +5862,6 @@
   <glossent id="trn_file">
 
     <gterm>.TRN file</gterm>
-
     <def>
 
       <para>

@@ -6957,11 +5873,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="mysql_enterprise_backup" />
-
     <gseealso glosid="innobackup_command" />
-
     <gseealso glosid="trg_file" />
 
   </glossent>

@@ -6969,7 +5882,6 @@
   <glossent id="two_phase_commit">
 
     <gterm>two-phase commit</gterm>
-
     <def>
 
       <para>

@@ -6984,13 +5896,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="xa" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="rollback" />
 
   </glossent>

@@ -6998,13 +5906,11 @@
   <glossent id="two_phase_locking">
 
     <gterm>two-phase locking</gterm>
-
     <def>
 
       <para></para>
 
     </def>
-
     <gseealso glosid="xa" />
 
   </glossent>

@@ -7012,7 +5918,6 @@
   <glossent id="transaction">
 
     <gterm>transaction</gterm>
-
     <def>
 
       <para>

@@ -7022,7 +5927,6 @@
         committed, or all the changes are undone when the transaction is
         rolled back.
       </para>
-
       <para>
         Database transactions, as implemented by InnoDB, have properties
         that are collectively known by the acronym

@@ -7031,15 +5935,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="acid" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="rollback" />
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="isolation_level" />
 
   </glossent>

@@ -7047,7 +5946,6 @@
   <glossent id="transaction_id">
 
     <gterm>transaction ID</gterm>
-
     <def>
 
       <para>

@@ -7057,7 +5955,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="implicit_row_lock" />
 
   </glossent>

@@ -7065,7 +5962,6 @@
   <glossent id="transportable_tablespace">
 
     <gterm>transportable tablespace</gterm>
-
     <def>
 
       <para>

@@ -7086,15 +5982,10 @@
       </para>
 
     </def>
-
     <gseealso glosid="tablespace" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="file_per_table" />
-
     <gseealso glosid="ibd_file" />
-
     <gseealso glosid="space_id" />
 
   </glossent>

@@ -7102,7 +5993,6 @@
   <glossent id="troubleshooting">
 
     <gterm>troubleshooting</gterm>
-
     <def>
 
       <para>

@@ -7117,7 +6007,6 @@
   <glossent id="tuple">
 
     <gterm>tuple</gterm>
-
     <def>
 
       <para>

@@ -7130,13 +6019,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="cursor" />
-
     <gseealso glosid="read_tuple" />
-
     <gseealso glosid="read_write_tuple" />
-
     <gseealso glosid="search_tuple" />
 
   </glossent>

@@ -7144,7 +6029,6 @@
   <glossent id="truncate">
 
     <gterm>truncate</gterm>
-
     <def>
 
       <para>

@@ -7157,7 +6041,6 @@
         one. Because this is a DDL operation, it cannot be
         <emphasis role="bold">rolled back</emphasis>.
       </para>
-
       <para>
         If the table being truncated contains foreign keys that
         reference another table, the truncation operation uses a slower

@@ -7167,9 +6050,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="ddl" />
-
     <gseealso glosid="rollback" />
 
   </glossent>

@@ -7177,7 +6058,6 @@
   <glossent id="undo_buffer">
 
     <gterm>undo buffer</gterm>
-
     <gsee glosid="undo_log" />
 
   </glossent>

@@ -7185,7 +6065,6 @@
   <glossent id="undo_log">
 
     <gterm>undo log</gterm>
-
     <def>
 
       <para>

@@ -7204,13 +6083,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="consistent_read" />
-
     <gseealso glosid="system_tablespace" />
-
     <gseealso glosid="rollback_segment" />
 
   </glossent>

@@ -7218,7 +6093,6 @@
   <glossent id="undo">
 
     <gterm>undo</gterm>
-
     <def>
 
       <para>

@@ -7229,11 +6103,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="undo_log" />
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="rollback" />
 
   </glossent>

@@ -7241,7 +6112,6 @@
   <glossent id="unique_constraint">
 
     <gterm>unique constraint</gterm>
-
     <def>
 
       <para>

@@ -7256,11 +6126,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="constraint" />
-
     <gseealso glosid="relational" />
-
     <gseealso glosid="unique_index" />
 
   </glossent>

@@ -7268,7 +6135,6 @@
   <glossent id="unique_index">
 
     <gterm>unique index</gterm>
-
     <def>
 
       <para>

@@ -7284,11 +6150,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="unique_constraint" />
-
     <gseealso glosid="unique_key" />
-
     <gseealso glosid="cardinality" />
 
   </glossent>

@@ -7296,7 +6159,6 @@
   <glossent id="unique_key">
 
     <gterm>unique key</gterm>
-
     <def>
 
       <para>

@@ -7308,11 +6170,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="unique_constraint" />
-
     <gseealso glosid="unique_index" />
-
     <gseealso glosid="cardinality" />
 
   </glossent>

@@ -7320,7 +6179,6 @@
   <glossent id="victim">
 
     <gterm>victim</gterm>
-
     <def>
 
       <para>

@@ -7331,11 +6189,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="innodb_lock_wait_timeout" />
-
     <gseealso glosid="deadlock" />
-
     <gseealso glosid="deadlock_detection" />
 
   </glossent>

@@ -7343,7 +6198,6 @@
   <glossent id="wait">
 
     <gterm>wait</gterm>
-
     <def>
 
       <para>

@@ -7358,7 +6212,6 @@
         scheduling, operating system <literal>wait()</literal> calls,
         and short-duration spin loops.
       </para>
-
       <para>
         On systems with heavy load and many transactions, you might use
         the output from the <literal>SHOW INNODB STATUS</literal>

@@ -7368,13 +6221,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="lock" />
-
     <gseealso glosid="mutex" />
-
     <gseealso glosid="latch" />
-
     <gseealso glosid="concurrency" />
 
   </glossent>

@@ -7382,7 +6231,6 @@
   <glossent id="warm_backup">
 
     <gterm>warm backup</gterm>
-
     <def>
 
       <para>

@@ -7394,11 +6242,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="backup" />
-
     <gseealso glosid="hot_backup" />
-
     <gseealso glosid="cold_backup" />
 
   </glossent>

@@ -7406,7 +6251,6 @@
   <glossent id="warm_up">
 
     <gterm>warm up</gterm>
-
     <def>
 
       <para>

@@ -7420,7 +6264,6 @@
       </para>
 
     </def>
-
     <gseealso glosid="buffer_pool" />
 
   </glossent>

@@ -7428,14 +6271,12 @@
   <glossent id="windows">
 
     <gterm>Windows</gterm>
-
     <def>
 
       <para>
         The built-in InnoDB storage engine and the InnoDB Plugin are
         supported on all the same Microsoft Windows versions as MySQL.
       </para>
-
       <para>
         The <emphasis role="bold">MySQL Enterprise Backup</emphasis>
         product is available on Windows, although the

@@ -7450,7 +6291,6 @@
   <glossent id="workload">
 
     <gterm>workload</gterm>
-
     <def>
 
       <para>

@@ -7464,9 +6304,7 @@
       </para>
 
     </def>
-
     <gseealso glosid="sql" />
-
     <gseealso glosid="bottleneck" />
 
   </glossent>

@@ -7474,7 +6312,6 @@
   <glossent id="write_combining">
 
     <gterm>write combining</gterm>
-
     <def>
 
       <para>

@@ -7488,11 +6325,8 @@
       </para>
 
     </def>
-
     <gseealso glosid="dirty_page" />
-
     <gseealso glosid="flush" />
-
     <gseealso glosid="buffer_pool" />
 
   </glossent>

@@ -7500,7 +6334,6 @@
   <glossent id="xa">
 
     <gterm>XA</gterm>
-
     <def>
 
       <para>

@@ -7509,7 +6342,6 @@
         databases to participate in a transaction while maintaining
         <emphasis role="bold">ACID</emphasis> compliance.
       </para>
-
       <para>
         XA Distributed Transaction support is turned on by default. If
         you are not using this feature, note that it adds an extra fsync

@@ -7517,13 +6349,9 @@
       </para>
 
     </def>
-
     <gseealso glosid="transaction" />
-
     <gseealso glosid="commit" />
-
     <gseealso glosid="two_phase_locking" />
-
     <gseealso glosid="two_phase_commit" />
 
   </glossent>


Modified: trunk/innodb-1.1/innodb-performance.xml
===================================================================
--- trunk/innodb-1.1/innodb-performance.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/innodb-1.1/innodb-performance.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 8; 2325 bytes

@@ -1536,7 +1536,7 @@
           <listitem>
             <para>
               <link linkend="glos_mutex">Mutexes</link> in the
-              <literal>MUTEX_INSTANCES</literal> table. (Mutexes and
+              <literal>mutex_instances</literal> table. (Mutexes and
               RW-locks related to the <literal>InnoDB</literal> buffer
               pool are not included in this coverage; the same applies
               to the output of the <literal>SHOW ENGINE INNODB

@@ -1547,22 +1547,22 @@
           <listitem>
             <para>
               <link linkend="glos_rw_lock">RW-locks</link> in the
-              <literal>RWLOCK_INSTANCES</literal> table.
+              <literal>rwlock_instances</literal> table.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              RW-locks in the <literal>RWLOCK_INSTANCES</literal> table.
+              RW-locks in the <literal>rwlock_instances</literal> table.
             </para>
           </listitem>
 
           <listitem>
             <para>
               File I/O operations in the
-              <literal>FILE_INSTANCES</literal>,
-              <literal>FILE_SUMMARY_BY_EVENT_NAME</literal>, and
-              <literal>FILE_SUMMARY_BY_INSTANCE</literal> tables.
+              <literal>file_instances</literal>,
+              <literal>file_summary_by_event_name</literal>, and
+              <literal>file_summary_by_instance</literal> tables.
             </para>
           </listitem>
 

@@ -1579,8 +1579,8 @@
       <listitem>
         <para>
           During performance testing, examine the performance data in
-          the <literal>EVENTS_WAITS_CURRENT</literal> and
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables. If you
+          the <literal>events_waits_current</literal> and
+          <literal>events_waits_history_long</literal> tables. If you
           are interested especially in InnoDB-related objects, use the
           clause <literal>where name like "%innodb%"</literal> to see
           just those entries; otherwise, examine the performance


Modified: trunk/innodb-plugin-1.1/innodb-performance.xml
===================================================================
--- trunk/innodb-plugin-1.1/innodb-performance.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/innodb-plugin-1.1/innodb-performance.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 8; 2346 bytes

@@ -1462,7 +1462,7 @@
           <listitem>
             <para>
               <link linkend="glos_mutex">Mutexes</link> in the
-              <literal>MUTEX_INSTANCES</literal> table. (Mutexes and
+              <literal>mutex_instances</literal> table. (Mutexes and
               RW-locks related to the <literal>InnoDB</literal> buffer
               pool are not included in this coverage; the same applies
               to the output of the <literal>SHOW ENGINE INNODB

@@ -1473,22 +1473,22 @@
           <listitem>
             <para>
               <link linkend="glos_rw_lock">RW-locks</link> in the
-              <literal>RWLOCK_INSTANCES</literal> table.
+              <literal>rwlock_instances</literal> table.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              RW-locks in the <literal>RWLOCK_INSTANCES</literal> table.
+              RW-locks in the <literal>rwlock_instances</literal> table.
             </para>
           </listitem>
 
           <listitem>
             <para>
               File I/O operations in the
-              <literal>FILE_INSTANCES</literal>,
-              <literal>FILE_SUMMARY_BY_EVENT_NAME</literal>, and
-              <literal>FILE_SUMMARY_BY_INSTANCE</literal> tables.
+              <literal>file_instances</literal>,
+              <literal>file_summary_by_event_name</literal>, and
+              <literal>file_summary_by_instance</literal> tables.
             </para>
           </listitem>
 

@@ -1505,8 +1505,8 @@
       <listitem>
         <para>
           During performance testing, examine the performance data in
-          the <literal>EVENTS_WAITS_CURRENT</literal> and
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables. If you
+          the <literal>events_waits_current</literal> and
+          <literal>events_waits_history_long</literal> tables. If you
           are interested especially in InnoDB-related objects, use the
           clause <literal>where name like "%innodb%"</literal> to see
           just those entries; otherwise, examine the performance


Modified: trunk/refman-5.5/optimization.xml
===================================================================
--- trunk/refman-5.5/optimization.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.5/optimization.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 2, Lines Deleted: 2; 881 bytes

@@ -12414,11 +12414,11 @@
 
     <section id="monitoring-performance-schema">
 
-      <title>Measuring Performance with <literal>PERFORMANCE_SCHEMA</literal></title>
+      <title>Measuring Performance with <literal>performance_schema</literal></title>
 
       <para>
         You can query the tables in the
-        <literal>PERFORMANCE_SCHEMA</literal> database to see real-time
+        <literal>performance_schema</literal> database to see real-time
         information about the performance characteristics of your server
         and the applications it is running. See
         <xref linkend="performance-schema"/> for details.


Modified: trunk/refman-5.5/performance-schema-core.xml
===================================================================
--- trunk/refman-5.5/performance-schema-core.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.5/performance-schema-core.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 82, Lines Added: 157, Lines Deleted: 157; 38920 bytes

@@ -240,7 +240,7 @@
   --performance_schema
                       Enable the performance schema.
   --performance_schema_events_waits_history_long_size=#
-                      Number of rows in EVENTS_WAITS_HISTORY_LONG.
+                      Number of rows in events_waits_history_long.
 ...
 </programlisting>
 

@@ -352,32 +352,32 @@
 +----------------------------------------------+
 | TABLE_NAME                                   |
 +----------------------------------------------+
-| COND_INSTANCES                               |
-| EVENTS_WAITS_CURRENT                         |
-| EVENTS_WAITS_HISTORY                         |
-| EVENTS_WAITS_HISTORY_LONG                    |
-| EVENTS_WAITS_SUMMARY_BY_INSTANCE             |
-| EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME |
-| EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME    |
-| FILE_INSTANCES                               |
-| FILE_SUMMARY_BY_EVENT_NAME                   |
-| FILE_SUMMARY_BY_INSTANCE                     |
-| MUTEX_INSTANCES                              |
-| PERFORMANCE_TIMERS                           |
-| RWLOCK_INSTANCES                             |
-| SETUP_CONSUMERS                              |
-| SETUP_INSTRUMENTS                            |
-| SETUP_TIMERS                                 |
-| THREADS                                      |
+| cond_instances                               |
+| events_waits_current                         |
+| events_waits_history                         |
+| events_waits_history_long                    |
+| events_waits_summary_by_instance             |
+| events_waits_summary_by_thread_by_event_name |
+| events_waits_summary_global_by_event_name    |
+| file_instances                               |
+| file_summary_by_event_name                   |
+| file_summary_by_instance                     |
+| mutex_instances                              |
+| performance_timers                           |
+| rwlock_instances                             |
+| setup_consumers                              |
+| setup_instruments                            |
+| setup_timers                                 |
+| threads                                      |
 +----------------------------------------------+
 
 mysql&gt; <userinput>SHOW TABLES FROM performance_schema;</userinput>
 +----------------------------------------------+
 | Tables_in_performance_schema                 |
 +----------------------------------------------+
-| COND_INSTANCES                               |
-| EVENTS_WAITS_CURRENT                         |
-| EVENTS_WAITS_HISTORY                         |
+| cond_instances                               |
+| events_waits_current                         |
+| events_waits_history                         |
 ...
 </programlisting>
 

@@ -404,10 +404,10 @@
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SHOW CREATE TABLE SETUP_TIMERS\G</userinput>
+mysql&gt; <userinput>SHOW CREATE TABLE setup_timers\G</userinput>
 *************************** 1. row ***************************
-       Table: SETUP_TIMERS
-Create Table: CREATE TABLE `SETUP_TIMERS` (
+       Table: setup_timers
+Create Table: CREATE TABLE `setup_timers` (
   `NAME` varchar(64) NOT NULL,
   `TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK')
    NOT NULL

@@ -432,7 +432,7 @@
 
     <para>
       To see what the server is doing at the moment, examine the
-      <literal>EVENTS_WAITS_CURRENT</literal> table. It contains one row
+      <literal>events_waits_current</literal> table. It contains one row
       per thread showing each thread's most recent monitored event:
     </para>
 

@@ -442,7 +442,7 @@
 -->
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM EVENTS_WAITS_CURRENT\G</userinput>
+mysql&gt; <userinput>SELECT * FROM events_waits_current\G</userinput>
 *************************** 1. row ***************************
             THREAD_ID: 0
              EVENT_ID: 5523

@@ -507,8 +507,8 @@
       current-events table but have more rows and show what the server
       has been doing <quote>recently</quote> rather than
       <quote>currently.</quote> The
-      <literal>EVENTS_WAITS_HISTORY</literal> and
-      <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables contain the
+      <literal>events_waits_history</literal> and
+      <literal>events_waits_history_long</literal> tables contain the
       most recent 10 events per thread and most recent 10,000 events,
       respectively. For example, to see information for recent events
       produced by thread 13, do this:

@@ -516,7 +516,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_HISTORY WHERE THREAD_ID = 13</userinput>
+    -&gt; <userinput>FROM events_waits_history WHERE THREAD_ID = 13</userinput>
     -&gt; <userinput>ORDER BY EVENT_ID;</userinput>
 +----------+-----------------------------------------+------------+
 | EVENT_ID | EVENT_NAME                              | TIMER_WAIT |

@@ -544,7 +544,7 @@
       time. The tables in this group summarize event data in different
       ways. To see which instruments have been executed the most times
       or have taken the most wait time, sort the
-      <literal>EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</literal> table
+      <literal>events_waits_summary_global_by_event_name</literal> table
       on the <literal>COUNT_STAR</literal> or
       <literal>SUM_TIMER_WAIT</literal> column, which correspond to a
       <literal>COUNT(*)</literal> or <literal>SUM(TIMER_WAIT)</literal>

@@ -553,7 +553,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT EVENT_NAME, COUNT_STAR</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</userinput>
+    -&gt; <userinput>FROM events_waits_summary_global_by_event_name</userinput>
     -&gt; <userinput>ORDER BY COUNT_STAR DESC LIMIT 10;</userinput>
 +---------------------------------------------------+------------+
 | EVENT_NAME                                        | COUNT_STAR |

@@ -571,7 +571,7 @@
 +---------------------------------------------------+------------+
 
 mysql&gt; <userinput>SELECT EVENT_NAME, SUM_TIMER_WAIT</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</userinput>
+    -&gt; <userinput>FROM events_waits_summary_global_by_event_name</userinput>
     -&gt; <userinput>ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;</userinput>
 +----------------------------------------+----------------+
 | EVENT_NAME                             | SUM_TIMER_WAIT |

@@ -608,12 +608,12 @@
       An instrumented object, when used by the server, produces an
       event. These tables provide event names and explanatory notes or
       status information. For example, the
-      <literal>FILE_INSTANCES</literal> table lists instances of
+      <literal>file_instances</literal> table lists instances of
       instruments for file I/O operations and their associated files:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM FILE_INSTANCES\G</userinput>
+mysql&gt; <userinput>SELECT * FROM file_instances\G</userinput>
 *************************** 1. row ***************************
  FILE_NAME: /opt/mysql-log/60500/binlog.000007
 EVENT_NAME: wait/io/file/sql/binlog

@@ -632,11 +632,11 @@
     <para>
       Setup tables are used to configure and display monitoring
       characteristics. For example, to see which event timer is
-      selected, query the <literal>SETUP_TIMERS</literal> tables:
+      selected, query the <literal>setup_timers</literal> tables:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -645,13 +645,13 @@
 </programlisting>
 
     <para>
-      <literal>SETUP_INSTRUMENTS</literal> lists the set of instruments
+      <literal>setup_instruments</literal> lists the set of instruments
       for which events can be collected and shows which of them are
       enabled:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -685,7 +685,7 @@
     </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';</userinput>
 </programlisting>
 

@@ -693,12 +693,12 @@
       Performance Schema uses collected events to update tables in the
       <literal>performance_schema</literal> database, which act as
       <quote>consumers</quote> of event information. The
-      <literal>SETUP_CONSUMERS</literal> table lists the available
+      <literal>setup_consumers</literal> table lists the available
       consumers and shows which of them are enabled:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -728,7 +728,7 @@
     <para>
       There are some miscellaneous tables that do not fall into any of
       the previous groups. For example,
-      <literal>PERFORMANCE_TIMERS</literal> lists the available event
+      <literal>performance_timers</literal> lists the available event
       timers and their characteristics. For information about timers,
       see <xref linkend="performance-schema-timing"/>.
     </para>

@@ -815,9 +815,9 @@
       </para>
 
 <programlisting>
-[ERROR] Native table 'performance_schema'.'EVENTS_WAITS_HISTORY'
+[ERROR] Native table 'performance_schema'.'events_waits_history'
 has the wrong structure
-[ERROR] Native table 'performance_schema'.'EVENTS_WAITS_HISTORY_LONG'
+[ERROR] Native table 'performance_schema'.'events_waits_history_long'
 has the wrong structure
 ...
 </programlisting>

@@ -835,7 +835,7 @@
   --performance_schema
                       Enable the performance schema.
   --performance_schema_events_waits_history_long_size=#
-                      Number of rows in EVENTS_WAITS_HISTORY_LONG.
+                      Number of rows in events_waits_history_long.
 ...
 </programlisting>
 

@@ -1026,9 +1026,9 @@
 +-------------------+
 | TABLE_NAME        |
 +-------------------+
-| SETUP_CONSUMERS   |
-| SETUP_INSTRUMENTS |
-| SETUP_TIMERS      |
+| setup_consumers   |
+| setup_instruments |
+| setup_timers      |
 +-------------------+
 </programlisting>
 

@@ -1044,11 +1044,11 @@
 
       <para>
         To see which event timer is selected, query the
-        <literal>SETUP_TIMERS</literal> tables:
+        <literal>setup_timers</literal> tables:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -1073,9 +1073,9 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_TIMERS SET TIMER_NAME = 'NANOSECOND';</userinput>
+mysql&gt; <userinput>UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND';</userinput>
 
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -1089,8 +1089,8 @@
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> and
-        <literal>SETUP_CONSUMERS</literal> tables list the instruments
+        The <literal>setup_instruments</literal> and
+        <literal>setup_consumers</literal> tables list the instruments
         for which events can be collected and the destination tables in
         which event information can be stored, respectively.
         <xref linkend="performance-schema-filtering"/>, discusses how

@@ -1128,12 +1128,12 @@
           <para>
             Instrumented code is the source for events and produces
             events to be collected. The
-            <literal>SETUP_INSTRUMENTS</literal> table lists the
+            <literal>setup_instruments</literal> table lists the
             instruments for which events can be collected:
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -1152,13 +1152,13 @@
         <listitem>
           <para>
             Performance Schema tables are the destinations for events
-            and consume events. The <literal>SETUP_CONSUMERS</literal>
+            and consume events. The <literal>setup_consumers</literal>
             table lists the destination tables in which event
             information can be stored:
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -1187,8 +1187,8 @@
       <para>
         Pre-filtering can be applied to either the producer or consumer
         stage of event processing by modifying the
-        <literal>SETUP_INSTRUMENTS</literal> or
-        <literal>SETUP_CONSUMERS</literal> table. An instrument or
+        <literal>setup_instruments</literal> or
+        <literal>setup_consumers</literal> table. An instrument or
         consumer can be enabled or disabled by setting its
         <literal>ENABLED</literal> value to <literal>YES</literal> or
         <literal>NO</literal>. An instrument can be configured whether

@@ -1256,7 +1256,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO';</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO';</userinput>
 </programlisting>
 
       <para>

@@ -1271,7 +1271,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/io/file/%';</userinput>
 </programlisting>
 

@@ -1280,7 +1280,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');</userinput>
 </programlisting>
 

@@ -1299,7 +1299,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;</userinput>
 </programlisting>
 

@@ -1308,7 +1308,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 

@@ -1318,7 +1318,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(ENABLED = 'YES', 'NO', 'YES')</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>

@@ -1340,7 +1340,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET TIMED = 'NO';</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET TIMED = 'NO';</userinput>
 </programlisting>
 
       <para>

@@ -1356,7 +1356,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 

@@ -1402,7 +1402,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT THREAD_ID, NUMBER_OF_BYTES</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_HISTORY</userinput>
+    -&gt; <userinput>FROM events_waits_history</userinput>
     -&gt; <userinput>WHERE EVENT_NAME LIKE 'wait/io/file/%'</userinput>
     -&gt; <userinput>AND NUMBER_OF_BYTES IS NOT NULL;</userinput>
 +-----------+-----------------+

@@ -1423,11 +1423,11 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';</userinput>
 
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME = 'file_summary_by_instance';</userinput>
 </programlisting>
 

@@ -1437,11 +1437,11 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/synch/mutex/%';</userinput>
 
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 

@@ -1472,9 +1472,9 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT NAME FROM SETUP_INSTRUMENTS WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
+mysql&gt; <userinput>SELECT NAME FROM setup_instruments WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 
-mysql&gt; <userinput>SELECT NAME FROM SETUP_CONSUMERS WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
+mysql&gt; <userinput>SELECT NAME FROM setup_consumers WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 </programlisting>
 
     </section>

@@ -1681,7 +1681,7 @@
       <listitem>
         <para>
           No row for the instrument is inserted into the
-          <literal>SETUP_INSTRUMENTS</literal> table.
+          <literal>setup_instruments</literal> table.
         </para>
       </listitem>
 

@@ -1766,7 +1766,7 @@
       If an instrument is not lost, it is known to the Performance
       Schema, and is used when instrumenting instances. For example,
       <literal>wait/synch/mutex/sql/LOCK_delete</literal> is the name of
-      a mutex instrument in the <literal>SETUP_INSTRUMENTS</literal>
+      a mutex instrument in the <literal>setup_instruments</literal>
       table. This single instrument is used when creating in the code
       (in <literal>THD::LOCK_delete</literal>) however many instances of
       the mutex are needed as the server runs. In this case,

@@ -1828,15 +1828,15 @@
 ...
 *************************** 3. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_SIZE
+  Name: events_waits_history.ROW_SIZE
 Status: 76
 *************************** 4. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_COUNT
+  Name: events_waits_history.ROW_COUNT
 Status: 10000
 *************************** 5. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.MEMORY
+  Name: events_waits_history.MEMORY
 Status: 760000
 ...
 *************************** 57. row ***************************

@@ -1871,7 +1871,7 @@
     <para>
       Timers vary in precision and the amount of overhead they involve.
       To see what timers are available and their characteristics, check
-      the <literal>PERFORMANCE_TIMERS</literal> table:
+      the <literal>performance_timers</literal> table:
     </para>
 
 <!--

@@ -1882,7 +1882,7 @@
 -->
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM PERFORMANCE_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM performance_timers;</userinput>
 +-------------+-----------------+------------------+----------------+
 | TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
 +-------------+-----------------+------------------+----------------+

@@ -1928,20 +1928,20 @@
 
     <para>
       To see which timer is in effect or to change the timer, access the
-      <literal>SETUP_TIMERS</literal> table, which has a single row:
+      <literal>setup_timers</literal> table, which has a single row:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+
 | wait | CYCLE      |
 +------+------------+
 
-mysql&gt; <userinput>UPDATE SETUP_TIMERS SET TIMER_NAME = 'MICROSECOND';</userinput>
+mysql&gt; <userinput>UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND';</userinput>
 
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+-------------+
 | NAME | TIMER_NAME  |
 +------+-------------+

@@ -2069,7 +2069,7 @@
     </para>
 
     <para>
-      The <literal>SETUP_INSTRUMENTS</literal> table has an
+      The <literal>setup_instruments</literal> table has an
       <literal>ENABLED</literal> column to indicate the instruments for
       which to collect events. The table also has a
       <literal>TIMED</literal> column to indicate which instruments are

@@ -2364,7 +2364,7 @@
       <listitem>
         <para>
           Current events table. The
-          <literal>EVENTS_WAITS_CURRENT</literal> table contains the
+          <literal>events_waits_current</literal> table contains the
           most recent event for each thread.
         </para>
       </listitem>

@@ -2372,10 +2372,10 @@
       <listitem>
         <para>
           History tables. These tables have the same structure as
-          <literal>EVENTS_WAITS_CURRENT</literal> but contain more rows.
-          The <literal>EVENTS_WAITS_HISTORY</literal> table contains the
+          <literal>events_waits_current</literal> but contain more rows.
+          The <literal>events_waits_history</literal> table contains the
           most recent 10 events per thread.
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> contains the most
+          <literal>events_waits_history_long</literal> contains the most
           recent 10,000 events.
         </para>
 

@@ -2446,19 +2446,19 @@
 +-------------------+
 | TABLE_NAME        |
 +-------------------+
-| SETUP_CONSUMERS   |
-| SETUP_INSTRUMENTS |
-| SETUP_TIMERS      |
+| setup_consumers   |
+| setup_instruments |
+| setup_timers      |
 +-------------------+
 </programlisting>
 
       <para>
-        The <literal>SETUP_CONSUMERS</literal> table lists destination
+        The <literal>setup_consumers</literal> table lists destination
         tables for event information:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -2474,7 +2474,7 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_CONSUMERS</literal> table has these columns:
+        The <literal>setup_consumers</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2507,18 +2507,18 @@
       <para>
         Disabling the <literal>events_waits_current</literal> consumer
         disables everything else that depends on waits, such as the
-        <literal>EVENTS_WAITS_HISTORY</literal> and
-        <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables, and all
+        <literal>events_waits_history</literal> and
+        <literal>events_waits_history_long</literal> tables, and all
         summary tables.
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> table lists classes of
+        The <literal>setup_instruments</literal> table lists classes of
         instrumented objects for which events can be collected:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -2540,7 +2540,7 @@
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> table has these
+        The <literal>setup_instruments</literal> table has these
         columns:
       </para>
 

@@ -2599,12 +2599,12 @@
       </itemizedlist>
 
       <para>
-        The <literal>SETUP_TIMERS</literal> table shows the currently
+        The <literal>setup_timers</literal> table shows the currently
         selected event timer:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -2613,15 +2613,15 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_TIMERS.TIMER_NAME</literal> value can be
+        The <literal>setup_timers.TIMER_NAME</literal> value can be
         changed to select a different timer. The value can be any of the
-        <literal>PERFORMANCE_TIMERS.TIMER_NAME</literal> values. For an
+        <literal>performance_timers.TIMER_NAME</literal> values. For an
         explanation of how event timing occurs, see
         <xref linkend="performance-schema-timing"/>.
       </para>
 
       <para>
-        The <literal>SETUP_TIMERS</literal> table has these columns:
+        The <literal>setup_timers</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2666,12 +2666,12 @@
 +----------------------+
 | TABLE_NAME           |
 +----------------------+
-| EVENTS_WAITS_CURRENT |
+| events_waits_current |
 +----------------------+
 </programlisting>
 
       <para>
-        The <literal>EVENTS_WAITS_CURRENT</literal> table contains a row
+        The <literal>events_waits_current</literal> table contains a row
         per thread showing the current status of each thread's most
         recent monitored event. When nesting events are implemented, it
         will be possible for a thread to have multiple events in

@@ -2685,7 +2685,7 @@
 
       <para>
         Of the tables that contain event rows,
-        <literal>EVENTS_WAITS_CURRENT</literal> is the most fundamental.
+        <literal>events_waits_current</literal> is the most fundamental.
         Other tables that contain event rows are logically derived from
         the current events. For example, the history tables are
         collections of the most recent events, up to a fixed number of

@@ -2693,7 +2693,7 @@
       </para>
 
       <para>
-        The <literal>EVENTS_WAITS_CURRENT</literal> table has these
+        The <literal>events_waits_current</literal> table has these
         columns:
       </para>
 

@@ -2720,7 +2720,7 @@
           <para>
             The name of the instrument from which the event was
             collected. This is a
-            <literal>SETUP_INSTRUMENTS.NAME</literal> value. Instrument
+            <literal>setup_instruments.NAME</literal> value. Instrument
             names have multiple parts and form a hierarchy, as discussed
             in <xref linkend="performance-schema-instrument-naming"/>.
           </para>

@@ -2940,14 +2940,14 @@
 +---------------------------+
 | TABLE_NAME                |
 +---------------------------+
-| EVENTS_WAITS_HISTORY      |
-| EVENTS_WAITS_HISTORY_LONG |
+| events_waits_history      |
+| events_waits_history_long |
 +---------------------------+
 </programlisting>
 
       <para>
-        The history tables, <literal>EVENTS_WAITS_HISTORY</literal> and
-        <literal>EVENTS_WAITS_HISTORY_LONG</literal>, contain the most
+        The history tables, <literal>events_waits_history</literal> and
+        <literal>events_waits_history_long</literal>, contain the most
         recent 10 events per thread and most recent 10,000 events,
         respectively. As new events are added to a history table, older
         events are discarded if the table is full. Events are not added

@@ -2961,7 +2961,7 @@
 
       <para>
         The history tables have the same structure as
-        <literal>EVENTS_WAITS_CURRENT</literal>. See
+        <literal>events_waits_current</literal>. See
         <xref linkend="performance-schema-current-tables"/>.
       </para>
 

@@ -2989,16 +2989,16 @@
 +----------------------------------------------+
 | TABLE_NAME                                   |
 +----------------------------------------------+
-| EVENTS_WAITS_SUMMARY_BY_INSTANCE             |
-| EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME |
-| EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME    |
-| FILE_SUMMARY_BY_EVENT_NAME                   |
-| FILE_SUMMARY_BY_INSTANCE                     |
+| events_waits_summary_by_instance             |
+| events_waits_summary_by_thread_by_event_name |
+| events_waits_summary_global_by_event_name    |
+| file_summary_by_event_name                   |
+| file_summary_by_instance                     |
 +----------------------------------------------+
 </programlisting>
 
       <para>
-        The <literal>EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</literal>
+        The <literal>events_waits_summary_global_by_event_name</literal>
         table was named
         <literal>EVENTS_WAITS_SUMMARY_BY_EVENT_NAME</literal> before
         MySQL 5.5.7.

@@ -3095,7 +3095,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</literal>
+            <literal>events_waits_summary_global_by_event_name</literal>
             has an <literal>EVENT_NAME</literal> column. Each row
             summarizes events for a given instrument. An instrument
             might be used to create multiple instances of the

@@ -3108,7 +3108,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_BY_INSTANCE</literal> has
+            <literal>events_waits_summary_by_instance</literal> has
             <literal>EVENT_NAME</literal> and
             <literal>OBJECT_INSTANCE_BEGIN</literal> columns. Each row
             summarizes events for a given instrument instance. If an

@@ -3121,7 +3121,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME</literal>
+            <literal>events_waits_summary_by_thread_by_event_name</literal>
             has <literal>THREAD_ID</literal> and
             <literal>EVENT_NAME</literal> columns. Each row summarizes
             events for a given thread and instrument.

@@ -3189,7 +3189,7 @@
 
         <listitem>
           <para>
-            <literal>FILE_SUMMARY_BY_EVENT_NAME</literal> has an
+            <literal>file_summary_by_event_name</literal> has an
             <literal>EVENT_NAME</literal> column. Each row summarizes
             events for a given instrument.
           </para>

@@ -3197,7 +3197,7 @@
 
         <listitem>
           <para>
-            <literal>FILE_SUMMARY_BY_INSTANCE</literal> has
+            <literal>file_summary_by_instance</literal> has
             <literal>FILE_NAME</literal> and
             <literal>EVENT_NAME</literal> columns. Each row summarizes
             events for a given file.

@@ -3211,7 +3211,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME\G</userinput>
+mysql&gt; <userinput>SELECT * FROM events_waits_summary_global_by_event_name\G</userinput>
 ...
 *************************** 6. row ***************************
     EVENT_NAME: wait/synch/mutex/sql/MYSQL_BIN_LOG::LOCK_index

@@ -3257,10 +3257,10 @@
 +------------------+
 | TABLE_NAME       |
 +------------------+
-| COND_INSTANCES   |
-| FILE_INSTANCES   |
-| MUTEX_INSTANCES  |
-| RWLOCK_INSTANCES |
+| cond_instances   |
+| file_instances   |
+| mutex_instances  |
+| rwlock_instances |
 +------------------+
 </programlisting>
 

@@ -3281,7 +3281,7 @@
       </para>
 
       <para>
-        The <literal>COND_INSTANCES</literal> table has these columns:
+        The <literal>cond_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3310,16 +3310,16 @@
       </itemizedlist>
 
       <para>
-        The <literal>FILE_INSTANCES</literal> table lists all the files
+        The <literal>file_instances</literal> table lists all the files
         seen by the Performance Schema when executing file I/O
         instrumentation. If a file on disk has never been opened, it
-        will not be in <literal>FILE_INSTANCES</literal>. When a file is
+        will not be in <literal>file_instances</literal>. When a file is
         deleted from the disk, it is also removed from the
-        <literal>FILE_INSTANCES</literal> table.
+        <literal>file_instances</literal> table.
       </para>
 
       <para>
-        The <literal>FILE_INSTANCES</literal> table has these columns:
+        The <literal>file_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3361,7 +3361,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>MUTEX_INSTANCES</literal> table has these columns:
+        The <literal>mutex_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3402,7 +3402,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>RWLOCK_INSTANCES</literal> table has these columns:
+        The <literal>rwlock_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3461,8 +3461,8 @@
       </itemizedlist>
 
       <para>
-        The <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal> and
-        <literal>RWLOCK_INSTANCES.WRITE_LOCKED_BY_THREAD_ID</literal>
+        The <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal> and
+        <literal>rwlock_instances.WRITE_LOCKED_BY_THREAD_ID</literal>
         columns are extremely important for investigating performance
         bottlenecks or deadlocks. For examples of how to use them for
         this purpose, see <xref linkend="performance-schema-examples"/>

@@ -3475,12 +3475,12 @@
       <title>Performance Schema Miscellaneous Tables</title>
 
       <para>
-        The <literal>PERFORMANCE_TIMERS</literal> table shows which
+        The <literal>performance_timers</literal> table shows which
         event timers are available:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM PERFORMANCE_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM performance_timers;</userinput>
 +-------------+-----------------+------------------+----------------+
 | TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
 +-------------+-----------------+------------------+----------------+

@@ -3500,7 +3500,7 @@
       </para>
 
       <para>
-        The <literal>PERFORMANCE_TIMERS</literal> table has these
+        The <literal>performance_timers</literal> table has these
         columns:
       </para>
 

@@ -3561,7 +3561,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>THREADS</literal> table has these columns:
+        The <literal>threads</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3613,7 +3613,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>THREADS</literal> table was named
+        The <literal>threads</literal> table was named
         <literal>PROCESSLIST</literal> before MySQL 5.5.6.
       </para>
 

@@ -3731,7 +3731,7 @@
 
         <para>
           The number of rows in the
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> table.
+          <literal>events_waits_history_long</literal> table.
         </para>
       </listitem>
 

@@ -3751,7 +3751,7 @@
 
         <para>
           The number of rows per thread in the
-          <literal>EVENTS_WAITS_HISTORY</literal> table.
+          <literal>events_waits_history</literal> table.
         </para>
       </listitem>
 

@@ -4206,7 +4206,7 @@
 
         <para>
           At each iteration, the Performance Schema output, particularly
-          the <literal>EVENTS_WAITS_HISTORY_LONG</literal> table, will
+          the <literal>events_waits_history_long</literal> table, will
           contain less and less <quote>noise</quote> caused by
           nonsignificant instruments, and given that this table has a
           fixed size, will contain more and more data relevant to the

@@ -4268,8 +4268,8 @@
     </orderedlist>
 
     <para>
-      The <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal> and
-      <literal>RWLOCK_INSTANCES.WRITE_LOCKED_BY_THREAD_ID</literal>
+      The <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal> and
+      <literal>rwlock_instances.WRITE_LOCKED_BY_THREAD_ID</literal>
       columns are extremely important for investigating performance
       bottlenecks or deadlocks. This is made possible by Performance
       Schema instrumentation as follows:

@@ -4289,13 +4289,13 @@
         </para>
 
 <programlisting>
-SELECT * FROM EVENTS_WAITS_CURRENT WHERE THREAD_ID = <replaceable>thread_1</replaceable>;
+SELECT * FROM events_waits_current WHERE THREAD_ID = <replaceable>thread_1</replaceable>;
 </programlisting>
 
         <para>
           Say the query result identifies that the thread is waiting for
           mutex A, found in
-          <literal>EVENTS_WAITS_CURRENT.OBJECT_INSTANCE_BEGIN</literal>.
+          <literal>events_waits_current.OBJECT_INSTANCE_BEGIN</literal>.
         </para>
       </listitem>
 

@@ -4305,13 +4305,13 @@
         </para>
 
 <programlisting>
-SELECT * FROM MUTEX_INSTANCES WHERE OBJECT_INSTANCE_BEGIN = <replaceable>mutex_A</replaceable>;
+SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = <replaceable>mutex_A</replaceable>;
 </programlisting>
 
         <para>
           Say the query result identifies that it is thread 2 holding
           mutex A, as found in
-          <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal>.
+          <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal>.
         </para>
       </listitem>
 

@@ -4321,7 +4321,7 @@
         </para>
 
 <programlisting>
-SELECT * FROM EVENTS_WAITS_CURRENT WHERE THREAD_ID = <replaceable>thread_2</replaceable>;
+SELECT * FROM events_waits_current WHERE THREAD_ID = <replaceable>thread_2</replaceable>;
 </programlisting>
       </listitem>
 


Modified: trunk/refman-5.5/restrictions.xml
===================================================================
--- trunk/refman-5.5/restrictions.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.5/restrictions.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 646 bytes

@@ -1585,7 +1585,7 @@
 
     <para>
       The types of timers might vary per platform. The
-      <literal>PERFORMANCE_TIMERS</literal> table shows which event
+      <literal>performance_timers</literal> table shows which event
       timers are available. If the values in this table for a given
       timer name are <literal>NULL</literal>, that timer is not
       supported on your platform.


Modified: trunk/refman-5.5/se-innodb-core.xml
===================================================================
--- trunk/refman-5.5/se-innodb-core.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.5/se-innodb-core.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 556 bytes

@@ -495,7 +495,7 @@
       <listitem>
         <para>
           You can monitor the performance details of the storage engine
-          by querying <literal>PERFORMANCE_SCHEMA</literal> tables.
+          by querying <literal>performance_schema</literal> tables.
         </para>
       </listitem>
 


Modified: trunk/refman-5.5/sql-syntax-server-administration.xml
===================================================================
--- trunk/refman-5.5/sql-syntax-server-administration.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.5/sql-syntax-server-administration.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 3, Lines Added: 7, Lines Deleted: 7; 2273 bytes

@@ -5825,15 +5825,15 @@
 ...
 *************************** 3. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_SIZE
+  Name: events_waits_history.ROW_SIZE
 Status: 76
 *************************** 4. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_COUNT
+  Name: events_waits_history.ROW_COUNT
 Status: 10000
 *************************** 5. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.MEMORY
+  Name: events_waits_history.MEMORY
 Status: 760000
 ...
 *************************** 57. row ***************************

@@ -5860,8 +5860,8 @@
             Internal buffers that are exposed as a table in the
             <literal>performance_schema</literal> are named after the
             table. Examples:
-            <literal>EVENTS_WAITS_HISTORY.ROW_SIZE</literal>,
-            <literal>MUTEX_INSTANCES.ROW_COUNT</literal>.
+            <literal>events_waits_history.ROW_SIZE</literal>,
+            <literal>mutex_instances.ROW_COUNT</literal>.
           </para>
         </listitem>
 

@@ -5922,11 +5922,11 @@
         In some cases, there is a direct relationship between a
         configuration parameter and a <literal>SHOW ENGINE</literal>
         value. For example,
-        <literal>EVENTS_WAITS_HISTORY_LONG.ROW_COUNT</literal>
+        <literal>events_waits_history_long.ROW_COUNT</literal>
         corresponds to
         <literal role="sysvar">performance_schema_events_waits_history_long_size</literal>.
         In other cases, the relationship is more complex. For example,
-        <literal>EVENTS_WAITS_HISTORY.ROW_COUNT</literal> corresponds to
+        <literal>events_waits_history.ROW_COUNT</literal> corresponds to
         <literal role="sysvar">performance_schema_events_waits_history_size</literal>
         (the number of rows per thread) multiplied by
         <literal role="sysvar">performance_schema_max_thread_instances</literal>


Modified: trunk/refman-5.5/triggers.xml
===================================================================
--- trunk/refman-5.5/triggers.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.5/triggers.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 674 bytes

@@ -37,7 +37,7 @@
       views, nor by changes to tables made by APIs that do not transmit
       SQL statements to the MySQL Server. This means that triggers are
       not activated by changes in <literal>INFORMATION_SCHEMA</literal>
-      or <literal>PERFORMANCE_SCHEMA</literal> tables, because these
+      or <literal>performance_schema</literal> tables, because these
       tables are actually views.
     </para>
   </important>


Modified: trunk/refman-5.6/performance-schema-core.xml
===================================================================
--- trunk/refman-5.6/performance-schema-core.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.6/performance-schema-core.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 88, Lines Added: 166, Lines Deleted: 166; 41224 bytes

@@ -240,7 +240,7 @@
   --performance_schema
                       Enable the performance schema.
   --performance_schema_events_waits_history_long_size=#
-                      Number of rows in EVENTS_WAITS_HISTORY_LONG.
+                      Number of rows in events_waits_history_long.
 ...
 </programlisting>
 

@@ -352,33 +352,33 @@
 +----------------------------------------------+
 | TABLE_NAME                                   |
 +----------------------------------------------+
-| COND_INSTANCES                               |
-| EVENTS_WAITS_CURRENT                         |
-| EVENTS_WAITS_HISTORY                         |
-| EVENTS_WAITS_HISTORY_LONG                    |
-| EVENTS_WAITS_SUMMARY_BY_INSTANCE             |
-| EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME |
-| EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME    |
-| FILE_INSTANCES                               |
-| FILE_SUMMARY_BY_EVENT_NAME                   |
-| FILE_SUMMARY_BY_INSTANCE                     |
-| MUTEX_INSTANCES                              |
-| PERFORMANCE_TIMERS                           |
-| RWLOCK_INSTANCES                             |
-| SETUP_ACTORS                                 |
-| SETUP_CONSUMERS                              |
-| SETUP_INSTRUMENTS                            |
-| SETUP_TIMERS                                 |
-| THREADS                                      |
+| cond_instances                               |
+| events_waits_current                         |
+| events_waits_history                         |
+| events_waits_history_long                    |
+| events_waits_summary_by_instance             |
+| events_waits_summary_by_thread_by_event_name |
+| events_waits_summary_global_by_event_name    |
+| file_instances                               |
+| file_summary_by_event_name                   |
+| file_summary_by_instance                     |
+| mutex_instances                              |
+| performance_timers                           |
+| rwlock_instances                             |
+| setup_actors                                 |
+| setup_consumers                              |
+| setup_instruments                            |
+| setup_timers                                 |
+| threads                                      |
 +----------------------------------------------+
 
 mysql&gt; <userinput>SHOW TABLES FROM performance_schema;</userinput>
 +----------------------------------------------+
 | Tables_in_performance_schema                 |
 +----------------------------------------------+
-| COND_INSTANCES                               |
-| EVENTS_WAITS_CURRENT                         |
-| EVENTS_WAITS_HISTORY                         |
+| cond_instances                               |
+| events_waits_current                         |
+| events_waits_history                         |
 ...
 </programlisting>
 

@@ -405,10 +405,10 @@
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SHOW CREATE TABLE SETUP_TIMERS\G</userinput>
+mysql&gt; <userinput>SHOW CREATE TABLE setup_timers\G</userinput>
 *************************** 1. row ***************************
-       Table: SETUP_TIMERS
-Create Table: CREATE TABLE `SETUP_TIMERS` (
+       Table: setup_timers
+Create Table: CREATE TABLE `setup_timers` (
   `NAME` varchar(64) NOT NULL,
   `TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK')
    NOT NULL

@@ -433,7 +433,7 @@
 
     <para>
       To see what the server is doing at the moment, examine the
-      <literal>EVENTS_WAITS_CURRENT</literal> table. It contains one row
+      <literal>events_waits_current</literal> table. It contains one row
       per thread showing each thread's most recent monitored event:
     </para>
 

@@ -443,7 +443,7 @@
 -->
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM EVENTS_WAITS_CURRENT\G</userinput>
+mysql&gt; <userinput>SELECT * FROM events_waits_current\G</userinput>
 *************************** 1. row ***************************
             THREAD_ID: 0
              EVENT_ID: 5523

@@ -508,8 +508,8 @@
       current-events table but have more rows and show what the server
       has been doing <quote>recently</quote> rather than
       <quote>currently.</quote> The
-      <literal>EVENTS_WAITS_HISTORY</literal> and
-      <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables contain the
+      <literal>events_waits_history</literal> and
+      <literal>events_waits_history_long</literal> tables contain the
       most recent 10 events per thread and most recent 10,000 events,
       respectively. For example, to see information for recent events
       produced by thread 13, do this:

@@ -517,7 +517,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_HISTORY WHERE THREAD_ID = 13</userinput>
+    -&gt; <userinput>FROM events_waits_history WHERE THREAD_ID = 13</userinput>
     -&gt; <userinput>ORDER BY EVENT_ID;</userinput>
 +----------+-----------------------------------------+------------+
 | EVENT_ID | EVENT_NAME                              | TIMER_WAIT |

@@ -545,7 +545,7 @@
       time. The tables in this group summarize event data in different
       ways. To see which instruments have been executed the most times
       or have taken the most wait time, sort the
-      <literal>EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</literal> table
+      <literal>events_waits_summary_global_by_event_name</literal> table
       on the <literal>COUNT_STAR</literal> or
       <literal>SUM_TIMER_WAIT</literal> column, which correspond to a
       <literal>COUNT(*)</literal> or <literal>SUM(TIMER_WAIT)</literal>

@@ -554,7 +554,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT EVENT_NAME, COUNT_STAR</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</userinput>
+    -&gt; <userinput>FROM events_waits_summary_global_by_event_name</userinput>
     -&gt; <userinput>ORDER BY COUNT_STAR DESC LIMIT 10;</userinput>
 +---------------------------------------------------+------------+
 | EVENT_NAME                                        | COUNT_STAR |

@@ -572,7 +572,7 @@
 +---------------------------------------------------+------------+
 
 mysql&gt; <userinput>SELECT EVENT_NAME, SUM_TIMER_WAIT</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</userinput>
+    -&gt; <userinput>FROM events_waits_summary_global_by_event_name</userinput>
     -&gt; <userinput>ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;</userinput>
 +----------------------------------------+----------------+
 | EVENT_NAME                             | SUM_TIMER_WAIT |

@@ -609,12 +609,12 @@
       An instrumented object, when used by the server, produces an
       event. These tables provide event names and explanatory notes or
       status information. For example, the
-      <literal>FILE_INSTANCES</literal> table lists instances of
+      <literal>file_instances</literal> table lists instances of
       instruments for file I/O operations and their associated files:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM FILE_INSTANCES\G</userinput>
+mysql&gt; <userinput>SELECT * FROM file_instances\G</userinput>
 *************************** 1. row ***************************
  FILE_NAME: /opt/mysql-log/60500/binlog.000007
 EVENT_NAME: wait/io/file/sql/binlog

@@ -633,11 +633,11 @@
     <para>
       Setup tables are used to configure and display monitoring
       characteristics. For example, to see which event timer is
-      selected, query the <literal>SETUP_TIMERS</literal> tables:
+      selected, query the <literal>setup_timers</literal> tables:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -646,13 +646,13 @@
 </programlisting>
 
     <para>
-      <literal>SETUP_INSTRUMENTS</literal> lists the set of instruments
+      <literal>setup_instruments</literal> lists the set of instruments
       for which events can be collected and shows which of them are
       enabled:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -686,7 +686,7 @@
     </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';</userinput>
 </programlisting>
 

@@ -694,12 +694,12 @@
       Performance Schema uses collected events to update tables in the
       <literal>performance_schema</literal> database, which act as
       <quote>consumers</quote> of event information. The
-      <literal>SETUP_CONSUMERS</literal> table lists the available
+      <literal>setup_consumers</literal> table lists the available
       consumers and shows which of them are enabled:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -729,7 +729,7 @@
     <para>
       There are some miscellaneous tables that do not fall into any of
       the previous groups. For example,
-      <literal>PERFORMANCE_TIMERS</literal> lists the available event
+      <literal>performance_timers</literal> lists the available event
       timers and their characteristics. For information about timers,
       see <xref linkend="performance-schema-timing"/>.
     </para>

@@ -816,9 +816,9 @@
       </para>
 
 <programlisting>
-[ERROR] Native table 'performance_schema'.'EVENTS_WAITS_HISTORY'
+[ERROR] Native table 'performance_schema'.'events_waits_history'
 has the wrong structure
-[ERROR] Native table 'performance_schema'.'EVENTS_WAITS_HISTORY_LONG'
+[ERROR] Native table 'performance_schema'.'events_waits_history_long'
 has the wrong structure
 ...
 </programlisting>

@@ -836,7 +836,7 @@
   --performance_schema
                       Enable the performance schema.
   --performance_schema_events_waits_history_long_size=#
-                      Number of rows in EVENTS_WAITS_HISTORY_LONG.
+                      Number of rows in events_waits_history_long.
 ...
 </programlisting>
 

@@ -1028,10 +1028,10 @@
 +-------------------+
 | TABLE_NAME        |
 +-------------------+
-| SETUP_ACTORS      |
-| SETUP_CONSUMERS   |
-| SETUP_INSTRUMENTS |
-| SETUP_TIMERS      |
+| setup_actors      |
+| setup_consumers   |
+| setup_instruments |
+| setup_timers      |
 +-------------------+
 </programlisting>
 

@@ -1047,11 +1047,11 @@
 
       <para>
         To see which event timer is selected, query the
-        <literal>SETUP_TIMERS</literal> tables:
+        <literal>setup_timers</literal> tables:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -1076,9 +1076,9 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_TIMERS SET TIMER_NAME = 'NANOSECOND';</userinput>
+mysql&gt; <userinput>UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND';</userinput>
 
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -1092,8 +1092,8 @@
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> and
-        <literal>SETUP_CONSUMERS</literal> tables list the instruments
+        The <literal>setup_instruments</literal> and
+        <literal>setup_consumers</literal> tables list the instruments
         for which events can be collected and the destination tables in
         which event information can be stored, respectively.
         <xref linkend="performance-schema-filtering"/>, discusses how

@@ -1131,12 +1131,12 @@
           <para>
             Instrumented code is the source for events and produces
             events to be collected. The
-            <literal>SETUP_INSTRUMENTS</literal> table lists the
+            <literal>setup_instruments</literal> table lists the
             instruments for which events can be collected:
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -1155,13 +1155,13 @@
         <listitem>
           <para>
             Performance Schema tables are the destinations for events
-            and consume events. The <literal>SETUP_CONSUMERS</literal>
+            and consume events. The <literal>setup_consumers</literal>
             table lists the destination tables in which event
             information can be stored:
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -1190,8 +1190,8 @@
       <para>
         Pre-filtering can be applied to either the producer or consumer
         stage of event processing by modifying the
-        <literal>SETUP_INSTRUMENTS</literal> or
-        <literal>SETUP_CONSUMERS</literal> table. An instrument or
+        <literal>setup_instruments</literal> or
+        <literal>setup_consumers</literal> table. An instrument or
         consumer can be enabled or disabled by setting its
         <literal>ENABLED</literal> value to <literal>YES</literal> or
         <literal>NO</literal>. An instrument can be configured whether

@@ -1259,7 +1259,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO';</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO';</userinput>
 </programlisting>
 
       <para>

@@ -1274,7 +1274,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/io/file/%';</userinput>
 </programlisting>
 

@@ -1283,7 +1283,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');</userinput>
 </programlisting>
 

@@ -1302,7 +1302,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;</userinput>
 </programlisting>
 

@@ -1311,7 +1311,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 

@@ -1321,7 +1321,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(ENABLED = 'YES', 'NO', 'YES')</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>

@@ -1343,7 +1343,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET TIMED = 'NO';</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET TIMED = 'NO';</userinput>
 </programlisting>
 
       <para>

@@ -1359,7 +1359,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 

@@ -1405,7 +1405,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT THREAD_ID, NUMBER_OF_BYTES</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_HISTORY</userinput>
+    -&gt; <userinput>FROM events_waits_history</userinput>
     -&gt; <userinput>WHERE EVENT_NAME LIKE 'wait/io/file/%'</userinput>
     -&gt; <userinput>AND NUMBER_OF_BYTES IS NOT NULL;</userinput>
 +-----------+-----------------+

@@ -1426,11 +1426,11 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';</userinput>
 
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME = 'file_summary_by_instance';</userinput>
 </programlisting>
 

@@ -1440,11 +1440,11 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/synch/mutex/%';</userinput>
 
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 

@@ -1475,9 +1475,9 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT NAME FROM SETUP_INSTRUMENTS WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
+mysql&gt; <userinput>SELECT NAME FROM setup_instruments WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 
-mysql&gt; <userinput>SELECT NAME FROM SETUP_CONSUMERS WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
+mysql&gt; <userinput>SELECT NAME FROM setup_consumers WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 </programlisting>
 
     </section>

@@ -1684,7 +1684,7 @@
       <listitem>
         <para>
           No row for the instrument is inserted into the
-          <literal>SETUP_INSTRUMENTS</literal> table.
+          <literal>setup_instruments</literal> table.
         </para>
       </listitem>
 

@@ -1769,7 +1769,7 @@
       If an instrument is not lost, it is known to the Performance
       Schema, and is used when instrumenting instances. For example,
       <literal>wait/synch/mutex/sql/LOCK_delete</literal> is the name of
-      a mutex instrument in the <literal>SETUP_INSTRUMENTS</literal>
+      a mutex instrument in the <literal>setup_instruments</literal>
       table. This single instrument is used when creating in the code
       (in <literal>THD::LOCK_delete</literal>) however many instances of
       the mutex are needed as the server runs. In this case,

@@ -1831,15 +1831,15 @@
 ...
 *************************** 3. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_SIZE
+  Name: events_waits_history.ROW_SIZE
 Status: 76
 *************************** 4. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_COUNT
+  Name: events_waits_history.ROW_COUNT
 Status: 10000
 *************************** 5. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.MEMORY
+  Name: events_waits_history.MEMORY
 Status: 760000
 ...
 *************************** 57. row ***************************

@@ -1874,7 +1874,7 @@
     <para>
       Timers vary in precision and the amount of overhead they involve.
       To see what timers are available and their characteristics, check
-      the <literal>PERFORMANCE_TIMERS</literal> table:
+      the <literal>performance_timers</literal> table:
     </para>
 
 <!--

@@ -1885,7 +1885,7 @@
 -->
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM PERFORMANCE_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM performance_timers;</userinput>
 +-------------+-----------------+------------------+----------------+
 | TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
 +-------------+-----------------+------------------+----------------+

@@ -1931,20 +1931,20 @@
 
     <para>
       To see which timer is in effect or to change the timer, access the
-      <literal>SETUP_TIMERS</literal> table, which has a single row:
+      <literal>setup_timers</literal> table, which has a single row:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+
 | wait | CYCLE      |
 +------+------------+
 
-mysql&gt; <userinput>UPDATE SETUP_TIMERS SET TIMER_NAME = 'MICROSECOND';</userinput>
+mysql&gt; <userinput>UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND';</userinput>
 
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+-------------+
 | NAME | TIMER_NAME  |
 +------+-------------+

@@ -2072,7 +2072,7 @@
     </para>
 
     <para>
-      The <literal>SETUP_INSTRUMENTS</literal> table has an
+      The <literal>setup_instruments</literal> table has an
       <literal>ENABLED</literal> column to indicate the instruments for
       which to collect events. The table also has a
       <literal>TIMED</literal> column to indicate which instruments are

@@ -2195,7 +2195,7 @@
                   Unlike most waits, a table I/O wait can include other
                   waits. For example, table I/O might include file I/O
                   or memory operations. Thus,
-                  <literal>EVENTS_WAITS_CURRENT</literal> for a table
+                  <literal>events_waits_current</literal> for a table
                   I/O wait usually has two rows. For more information,
                   see
                   <xref linkend="performance-schema-atom-molecule-events"/>.

@@ -2315,7 +2315,7 @@
 
     <para>
       For a table I/O event, there are usually two rows in
-      <literal>EVENTS_WAITS_CURRENT</literal>, not one. For example, a
+      <literal>events_waits_current</literal>, not one. For example, a
       row fetch might result in rows like this:
     </para>
 

@@ -2338,7 +2338,7 @@
       This occurs because, unlike other <quote>atomic</quote> wait
       events such as for mutexes or file I/O, table I/O events are
       <quote>molecular</quote> and include (overlap with) other events.
-      In <literal>EVENTS_WAITS_CURRENT</literal>, the table I/O event
+      In <literal>events_waits_current</literal>, the table I/O event
       usually has two rows:
     </para>
 

@@ -2362,7 +2362,7 @@
       Usually, but not always, the <quote>of any kind</quote> wait event
       differs from the table I/O event. As each subsidiary event
       completes, it disappears from
-      <literal>EVENTS_WAITS_CURRENT</literal>. At this point, and until
+      <literal>events_waits_current</literal>. At this point, and until
       the next subsidiary event begins, the table I/O wait is also the
       most recent wait of any kind.
     </para>

@@ -2458,7 +2458,7 @@
       <listitem>
         <para>
           Current events table. The
-          <literal>EVENTS_WAITS_CURRENT</literal> table contains the
+          <literal>events_waits_current</literal> table contains the
           most recent event for each thread.
         </para>
       </listitem>

@@ -2466,10 +2466,10 @@
       <listitem>
         <para>
           History tables. These tables have the same structure as
-          <literal>EVENTS_WAITS_CURRENT</literal> but contain more rows.
-          The <literal>EVENTS_WAITS_HISTORY</literal> table contains the
+          <literal>events_waits_current</literal> but contain more rows.
+          The <literal>events_waits_history</literal> table contains the
           most recent 10 events per thread.
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> contains the most
+          <literal>events_waits_history_long</literal> contains the most
           recent 10,000 events.
         </para>
 

@@ -2540,20 +2540,20 @@
 +-------------------+
 | TABLE_NAME        |
 +-------------------+
-| SETUP_ACTORS      |
-| SETUP_CONSUMERS   |
-| SETUP_INSTRUMENTS |
-| SETUP_TIMERS      |
+| setup_actors      |
+| setup_consumers   |
+| setup_instruments |
+| setup_timers      |
 +-------------------+
 </programlisting>
 
       <para>
-        The <literal>SETUP_ACTORS</literal> table lists information that
+        The <literal>setup_actors</literal> table lists information that
         determines whether new threads are monitored:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_ACTORS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_actors;</userinput>
 +------+------+------+
 | HOST | USER | ROLE |
 +------+------+------+

@@ -2562,7 +2562,7 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_ACTORS</literal> table has these columns:
+        The <literal>setup_actors</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2600,12 +2600,12 @@
       </itemizedlist>
 
       <para>
-        The <literal>SETUP_CONSUMERS</literal> table lists destination
+        The <literal>setup_consumers</literal> table lists destination
         tables for event information:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -2621,7 +2621,7 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_CONSUMERS</literal> table has these columns:
+        The <literal>setup_consumers</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2654,18 +2654,18 @@
       <para>
         Disabling the <literal>events_waits_current</literal> consumer
         disables everything else that depends on waits, such as the
-        <literal>EVENTS_WAITS_HISTORY</literal> and
-        <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables, and all
+        <literal>events_waits_history</literal> and
+        <literal>events_waits_history_long</literal> tables, and all
         summary tables.
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> table lists classes of
+        The <literal>setup_instruments</literal> table lists classes of
         instrumented objects for which events can be collected:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -2687,7 +2687,7 @@
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> table has these
+        The <literal>setup_instruments</literal> table has these
         columns:
       </para>
 

@@ -2746,12 +2746,12 @@
       </itemizedlist>
 
       <para>
-        The <literal>SETUP_TIMERS</literal> table shows the currently
+        The <literal>setup_timers</literal> table shows the currently
         selected event timer:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -2760,15 +2760,15 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_TIMERS.TIMER_NAME</literal> value can be
+        The <literal>setup_timers.TIMER_NAME</literal> value can be
         changed to select a different timer. The value can be any of the
-        <literal>PERFORMANCE_TIMERS.TIMER_NAME</literal> values. For an
+        <literal>performance_timers.TIMER_NAME</literal> values. For an
         explanation of how event timing occurs, see
         <xref linkend="performance-schema-timing"/>.
       </para>
 
       <para>
-        The <literal>SETUP_TIMERS</literal> table has these columns:
+        The <literal>setup_timers</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2813,12 +2813,12 @@
 +----------------------+
 | TABLE_NAME           |
 +----------------------+
-| EVENTS_WAITS_CURRENT |
+| events_waits_current |
 +----------------------+
 </programlisting>
 
       <para>
-        The <literal>EVENTS_WAITS_CURRENT</literal> table contains a row
+        The <literal>events_waits_current</literal> table contains a row
         per thread showing the current status of each thread's most
         recent monitored event. When nesting events are implemented, it
         will be possible for a thread to have multiple events in

@@ -2832,7 +2832,7 @@
 
       <para>
         Of the tables that contain event rows,
-        <literal>EVENTS_WAITS_CURRENT</literal> is the most fundamental.
+        <literal>events_waits_current</literal> is the most fundamental.
         Other tables that contain event rows are logically derived from
         the current events. For example, the history tables are
         collections of the most recent events, up to a fixed number of

@@ -2840,7 +2840,7 @@
       </para>
 
       <para>
-        The <literal>EVENTS_WAITS_CURRENT</literal> table has these
+        The <literal>events_waits_current</literal> table has these
         columns:
       </para>
 

@@ -2867,7 +2867,7 @@
           <para>
             The name of the instrument from which the event was
             collected. This is a
-            <literal>SETUP_INSTRUMENTS.NAME</literal> value. Instrument
+            <literal>setup_instruments.NAME</literal> value. Instrument
             names have multiple parts and form a hierarchy, as discussed
             in <xref linkend="performance-schema-instrument-naming"/>.
           </para>

@@ -3126,14 +3126,14 @@
 +---------------------------+
 | TABLE_NAME                |
 +---------------------------+
-| EVENTS_WAITS_HISTORY      |
-| EVENTS_WAITS_HISTORY_LONG |
+| events_waits_history      |
+| events_waits_history_long |
 +---------------------------+
 </programlisting>
 
       <para>
-        The history tables, <literal>EVENTS_WAITS_HISTORY</literal> and
-        <literal>EVENTS_WAITS_HISTORY_LONG</literal>, contain the most
+        The history tables, <literal>events_waits_history</literal> and
+        <literal>events_waits_history_long</literal>, contain the most
         recent 10 events per thread and most recent 10,000 events,
         respectively. As new events are added to a history table, older
         events are discarded if the table is full. Events are not added

@@ -3147,7 +3147,7 @@
 
       <para>
         The history tables have the same structure as
-        <literal>EVENTS_WAITS_CURRENT</literal>. See
+        <literal>events_waits_current</literal>. See
         <xref linkend="performance-schema-current-tables"/>.
       </para>
 

@@ -3175,11 +3175,11 @@
 +----------------------------------------------+
 | TABLE_NAME                                   |
 +----------------------------------------------+
-| EVENTS_WAITS_SUMMARY_BY_INSTANCE             |
-| EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME |
-| EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME    |
-| FILE_SUMMARY_BY_EVENT_NAME                   |
-| FILE_SUMMARY_BY_INSTANCE                     |
+| events_waits_summary_by_instance             |
+| events_waits_summary_by_thread_by_event_name |
+| events_waits_summary_global_by_event_name    |
+| file_summary_by_event_name                   |
+| file_summary_by_instance                     |
 +----------------------------------------------+
 </programlisting>
 

@@ -3274,7 +3274,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME</literal>
+            <literal>events_waits_summary_global_by_event_name</literal>
             has an <literal>EVENT_NAME</literal> column. Each row
             summarizes events for a given instrument. An instrument
             might be used to create multiple instances of the

@@ -3287,7 +3287,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_BY_INSTANCE</literal> has
+            <literal>events_waits_summary_by_instance</literal> has
             <literal>EVENT_NAME</literal> and
             <literal>OBJECT_INSTANCE_BEGIN</literal> columns. Each row
             summarizes events for a given instrument instance. If an

@@ -3300,7 +3300,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME</literal>
+            <literal>events_waits_summary_by_thread_by_event_name</literal>
             has <literal>THREAD_ID</literal> and
             <literal>EVENT_NAME</literal> columns. Each row summarizes
             events for a given thread and instrument.

@@ -3368,7 +3368,7 @@
 
         <listitem>
           <para>
-            <literal>FILE_SUMMARY_BY_EVENT_NAME</literal> has an
+            <literal>file_summary_by_event_name</literal> has an
             <literal>EVENT_NAME</literal> column. Each row summarizes
             events for a given instrument.
           </para>

@@ -3376,7 +3376,7 @@
 
         <listitem>
           <para>
-            <literal>FILE_SUMMARY_BY_INSTANCE</literal> has
+            <literal>file_summary_by_instance</literal> has
             <literal>FILE_NAME</literal> and
             <literal>EVENT_NAME</literal> columns. Each row summarizes
             events for a given file.

@@ -3390,7 +3390,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME\G</userinput>
+mysql&gt; <userinput>SELECT * FROM events_waits_summary_global_by_event_name\G</userinput>
 ...
 *************************** 6. row ***************************
     EVENT_NAME: wait/synch/mutex/sql/MYSQL_BIN_LOG::LOCK_index

@@ -3436,10 +3436,10 @@
 +------------------+
 | TABLE_NAME       |
 +------------------+
-| COND_INSTANCES   |
-| FILE_INSTANCES   |
-| MUTEX_INSTANCES  |
-| RWLOCK_INSTANCES |
+| cond_instances   |
+| file_instances   |
+| mutex_instances  |
+| rwlock_instances |
 +------------------+
 </programlisting>
 

@@ -3460,7 +3460,7 @@
       </para>
 
       <para>
-        The <literal>COND_INSTANCES</literal> table has these columns:
+        The <literal>cond_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3489,16 +3489,16 @@
       </itemizedlist>
 
       <para>
-        The <literal>FILE_INSTANCES</literal> table lists all the files
+        The <literal>file_instances</literal> table lists all the files
         seen by the Performance Schema when executing file I/O
         instrumentation. If a file on disk has never been opened, it
-        will not be in <literal>FILE_INSTANCES</literal>. When a file is
+        will not be in <literal>file_instances</literal>. When a file is
         deleted from the disk, it is also removed from the
-        <literal>FILE_INSTANCES</literal> table.
+        <literal>file_instances</literal> table.
       </para>
 
       <para>
-        The <literal>FILE_INSTANCES</literal> table has these columns:
+        The <literal>file_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3540,7 +3540,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>MUTEX_INSTANCES</literal> table has these columns:
+        The <literal>mutex_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3581,7 +3581,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>RWLOCK_INSTANCES</literal> table has these columns:
+        The <literal>rwlock_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3640,8 +3640,8 @@
       </itemizedlist>
 
       <para>
-        The <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal> and
-        <literal>RWLOCK_INSTANCES.WRITE_LOCKED_BY_THREAD_ID</literal>
+        The <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal> and
+        <literal>rwlock_instances.WRITE_LOCKED_BY_THREAD_ID</literal>
         columns are extremely important for investigating performance
         bottlenecks or deadlocks. For examples of how to use them for
         this purpose, see <xref linkend="performance-schema-examples"/>

@@ -3654,12 +3654,12 @@
       <title>Performance Schema Miscellaneous Tables</title>
 
       <para>
-        The <literal>PERFORMANCE_TIMERS</literal> table shows which
+        The <literal>performance_timers</literal> table shows which
         event timers are available:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM PERFORMANCE_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM performance_timers;</userinput>
 +-------------+-----------------+------------------+----------------+
 | TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
 +-------------+-----------------+------------------+----------------+

@@ -3679,7 +3679,7 @@
       </para>
 
       <para>
-        The <literal>PERFORMANCE_TIMERS</literal> table has these
+        The <literal>performance_timers</literal> table has these
         columns:
       </para>
 

@@ -3740,7 +3740,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>THREADS</literal> table has these columns:
+        The <literal>threads</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -4011,7 +4011,7 @@
 
         <para>
           The number of rows in the
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> table.
+          <literal>events_waits_history_long</literal> table.
         </para>
       </listitem>
 

@@ -4031,7 +4031,7 @@
 
         <para>
           The number of rows per thread in the
-          <literal>EVENTS_WAITS_HISTORY</literal> table.
+          <literal>events_waits_history</literal> table.
         </para>
       </listitem>
 

@@ -4326,7 +4326,7 @@
         </para>
 
         <para>
-          The number of rows in the <literal>SETUP_ACTORS</literal>
+          The number of rows in the <literal>setup_actors</literal>
           table.
         </para>
       </listitem>

@@ -4506,7 +4506,7 @@
 
         <para>
           At each iteration, the Performance Schema output, particularly
-          the <literal>EVENTS_WAITS_HISTORY_LONG</literal> table, will
+          the <literal>events_waits_history_long</literal> table, will
           contain less and less <quote>noise</quote> caused by
           nonsignificant instruments, and given that this table has a
           fixed size, will contain more and more data relevant to the

@@ -4568,8 +4568,8 @@
     </orderedlist>
 
     <para>
-      The <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal> and
-      <literal>RWLOCK_INSTANCES.WRITE_LOCKED_BY_THREAD_ID</literal>
+      The <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal> and
+      <literal>rwlock_instances.WRITE_LOCKED_BY_THREAD_ID</literal>
       columns are extremely important for investigating performance
       bottlenecks or deadlocks. This is made possible by Performance
       Schema instrumentation as follows:

@@ -4589,13 +4589,13 @@
         </para>
 
 <programlisting>
-SELECT * FROM EVENTS_WAITS_CURRENT WHERE THREAD_ID = <replaceable>thread_1</replaceable>;
+SELECT * FROM events_waits_current WHERE THREAD_ID = <replaceable>thread_1</replaceable>;
 </programlisting>
 
         <para>
           Say the query result identifies that the thread is waiting for
           mutex A, found in
-          <literal>EVENTS_WAITS_CURRENT.OBJECT_INSTANCE_BEGIN</literal>.
+          <literal>events_waits_current.OBJECT_INSTANCE_BEGIN</literal>.
         </para>
       </listitem>
 

@@ -4605,13 +4605,13 @@
         </para>
 
 <programlisting>
-SELECT * FROM MUTEX_INSTANCES WHERE OBJECT_INSTANCE_BEGIN = <replaceable>mutex_A</replaceable>;
+SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = <replaceable>mutex_A</replaceable>;
 </programlisting>
 
         <para>
           Say the query result identifies that it is thread 2 holding
           mutex A, as found in
-          <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal>.
+          <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal>.
         </para>
       </listitem>
 

@@ -4621,7 +4621,7 @@
         </para>
 
 <programlisting>
-SELECT * FROM EVENTS_WAITS_CURRENT WHERE THREAD_ID = <replaceable>thread_2</replaceable>;
+SELECT * FROM events_waits_current WHERE THREAD_ID = <replaceable>thread_2</replaceable>;
 </programlisting>
       </listitem>
 


Modified: trunk/refman-5.6/restrictions.xml
===================================================================
--- trunk/refman-5.6/restrictions.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.6/restrictions.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 646 bytes

@@ -1584,7 +1584,7 @@
 
     <para>
       The types of timers might vary per platform. The
-      <literal>PERFORMANCE_TIMERS</literal> table shows which event
+      <literal>performance_timers</literal> table shows which event
       timers are available. If the values in this table for a given
       timer name are <literal>NULL</literal>, that timer is not
       supported on your platform.


Modified: trunk/refman-5.6/sql-syntax-server-administration.xml
===================================================================
--- trunk/refman-5.6/sql-syntax-server-administration.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.6/sql-syntax-server-administration.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 3, Lines Added: 7, Lines Deleted: 7; 2273 bytes

@@ -5819,15 +5819,15 @@
 ...
 *************************** 3. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_SIZE
+  Name: events_waits_history.ROW_SIZE
 Status: 76
 *************************** 4. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_COUNT
+  Name: events_waits_history.ROW_COUNT
 Status: 10000
 *************************** 5. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.MEMORY
+  Name: events_waits_history.MEMORY
 Status: 760000
 ...
 *************************** 57. row ***************************

@@ -5854,8 +5854,8 @@
             Internal buffers that are exposed as a table in the
             <literal>performance_schema</literal> are named after the
             table. Examples:
-            <literal>EVENTS_WAITS_HISTORY.ROW_SIZE</literal>,
-            <literal>MUTEX_INSTANCES.ROW_COUNT</literal>.
+            <literal>events_waits_history.ROW_SIZE</literal>,
+            <literal>mutex_instances.ROW_COUNT</literal>.
           </para>
         </listitem>
 

@@ -5916,11 +5916,11 @@
         In some cases, there is a direct relationship between a
         configuration parameter and a <literal>SHOW ENGINE</literal>
         value. For example,
-        <literal>EVENTS_WAITS_HISTORY_LONG.ROW_COUNT</literal>
+        <literal>events_waits_history_long.ROW_COUNT</literal>
         corresponds to
         <literal role="sysvar">performance_schema_events_waits_history_long_size</literal>.
         In other cases, the relationship is more complex. For example,
-        <literal>EVENTS_WAITS_HISTORY.ROW_COUNT</literal> corresponds to
+        <literal>events_waits_history.ROW_COUNT</literal> corresponds to
         <literal role="sysvar">performance_schema_events_waits_history_size</literal>
         (the number of rows per thread) multiplied by
         <literal role="sysvar">performance_schema_max_thread_instances</literal>


Modified: trunk/refman-5.6/triggers.xml
===================================================================
--- trunk/refman-5.6/triggers.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-5.6/triggers.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 674 bytes

@@ -37,7 +37,7 @@
       views, nor by changes to tables made by APIs that do not transmit
       SQL statements to the MySQL Server. This means that triggers are
       not activated by changes in <literal>INFORMATION_SCHEMA</literal>
-      or <literal>PERFORMANCE_SCHEMA</literal> tables, because these
+      or <literal>performance_schema</literal> tables, because these
       tables are actually views.
     </para>
   </important>


Modified: trunk/refman-6.0/performance-schema-core.xml
===================================================================
--- trunk/refman-6.0/performance-schema-core.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-6.0/performance-schema-core.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 75, Lines Added: 146, Lines Deleted: 146; 35799 bytes

@@ -240,7 +240,7 @@
   --performance_schema
                       Enable the performance schema.
   --performance_schema_events_waits_history_long_size=#
-                      Number of rows in EVENTS_WAITS_HISTORY_LONG.
+                      Number of rows in events_waits_history_long.
 ...
 </programlisting>
 

@@ -352,33 +352,33 @@
 +----------------------------------------------+
 | TABLE_NAME                                   |
 +----------------------------------------------+
-| COND_INSTANCES                               |
-| EVENTS_WAITS_CURRENT                         |
-| EVENTS_WAITS_HISTORY                         |
-| EVENTS_WAITS_HISTORY_LONG                    |
+| cond_instances                               |
+| events_waits_current                         |
+| events_waits_history                         |
+| events_waits_history_long                    |
 | EVENTS_WAITS_SUMMARY_BY_EVENT_NAME           |
-| EVENTS_WAITS_SUMMARY_BY_INSTANCE             |
-| EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME |
-| FILE_INSTANCES                               |
-| FILE_SUMMARY_BY_EVENT_NAME                   |
-| FILE_SUMMARY_BY_INSTANCE                     |
-| MUTEX_INSTANCES                              |
-| PERFORMANCE_TIMERS                           |
+| events_waits_summary_by_instance             |
+| events_waits_summary_by_thread_by_event_name |
+| file_instances                               |
+| file_summary_by_event_name                   |
+| file_summary_by_instance                     |
+| mutex_instances                              |
+| performance_timers                           |
 | PROCESSLIST                                  |
-| RWLOCK_INSTANCES                             |
-| SETUP_CONSUMERS                              |
-| SETUP_INSTRUMENTS                            |
+| rwlock_instances                             |
+| setup_consumers                              |
+| setup_instruments                            |
 | SETUP_OBJECTS                                |
-| SETUP_TIMERS                                 |
+| setup_timers                                 |
 +----------------------------------------------+
 
 mysql&gt; <userinput>SHOW TABLES FROM performance_schema;</userinput>
 +----------------------------------------------+
 | Tables_in_performance_schema                 |
 +----------------------------------------------+
-| COND_INSTANCES                               |
-| EVENTS_WAITS_CURRENT                         |
-| EVENTS_WAITS_HISTORY                         |
+| cond_instances                               |
+| events_waits_current                         |
+| events_waits_history                         |
 ...
 </programlisting>
 

@@ -405,10 +405,10 @@
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SHOW CREATE TABLE SETUP_TIMERS\G</userinput>
+mysql&gt; <userinput>SHOW CREATE TABLE setup_timers\G</userinput>
 *************************** 1. row ***************************
-       Table: SETUP_TIMERS
-Create Table: CREATE TABLE `SETUP_TIMERS` (
+       Table: setup_timers
+Create Table: CREATE TABLE `setup_timers` (
   `NAME` varchar(64) NOT NULL,
   `TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK')
    NOT NULL

@@ -433,7 +433,7 @@
 
     <para>
       To see what the server is doing at the moment, examine the
-      <literal>EVENTS_WAITS_CURRENT</literal> table. It contains one row
+      <literal>events_waits_current</literal> table. It contains one row
       per thread showing each thread's most recent monitored event:
     </para>
 

@@ -443,7 +443,7 @@
 -->
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM EVENTS_WAITS_CURRENT\G</userinput>
+mysql&gt; <userinput>SELECT * FROM events_waits_current\G</userinput>
 *************************** 1. row ***************************
             THREAD_ID: 0
              EVENT_ID: 5523

@@ -508,8 +508,8 @@
       current-events table but have more rows and show what the server
       has been doing <quote>recently</quote> rather than
       <quote>currently.</quote> The
-      <literal>EVENTS_WAITS_HISTORY</literal> and
-      <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables contain the
+      <literal>events_waits_history</literal> and
+      <literal>events_waits_history_long</literal> tables contain the
       most recent 10 events per thread and most recent 10,000 events,
       respectively. For example, to see information for recent events
       produced by thread 13, do this:

@@ -517,7 +517,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_HISTORY WHERE THREAD_ID = 13</userinput>
+    -&gt; <userinput>FROM events_waits_history WHERE THREAD_ID = 13</userinput>
     -&gt; <userinput>ORDER BY EVENT_ID;</userinput>
 +----------+-----------------------------------------+------------+
 | EVENT_ID | EVENT_NAME                              | TIMER_WAIT |

@@ -609,12 +609,12 @@
       An instrumented object, when used by the server, produces an
       event. These tables provide event names and explanatory notes or
       status information. For example, the
-      <literal>FILE_INSTANCES</literal> table lists instances of
+      <literal>file_instances</literal> table lists instances of
       instruments for file I/O operations and their associated files:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM FILE_INSTANCES\G</userinput>
+mysql&gt; <userinput>SELECT * FROM file_instances\G</userinput>
 *************************** 1. row ***************************
  FILE_NAME: /opt/mysql-log/60500/binlog.000007
 EVENT_NAME: wait/io/file/sql/binlog

@@ -633,11 +633,11 @@
     <para>
       Setup tables are used to configure and display monitoring
       characteristics. For example, to see which event timer is
-      selected, query the <literal>SETUP_TIMERS</literal> tables:
+      selected, query the <literal>setup_timers</literal> tables:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -646,13 +646,13 @@
 </programlisting>
 
     <para>
-      <literal>SETUP_INSTRUMENTS</literal> lists the set of instruments
+      <literal>setup_instruments</literal> lists the set of instruments
       for which events can be collected and shows which of them are
       enabled:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -686,7 +686,7 @@
     </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';</userinput>
 </programlisting>
 

@@ -694,12 +694,12 @@
       Performance Schema uses collected events to update tables in the
       <literal>performance_schema</literal> database, which act as
       <quote>consumers</quote> of event information. The
-      <literal>SETUP_CONSUMERS</literal> table lists the available
+      <literal>setup_consumers</literal> table lists the available
       consumers and shows which of them are enabled:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -729,7 +729,7 @@
     <para>
       There are some miscellaneous tables that do not fall into any of
       the previous groups. For example,
-      <literal>PERFORMANCE_TIMERS</literal> lists the available event
+      <literal>performance_timers</literal> lists the available event
       timers and their characteristics. For information about timers,
       see <xref linkend="performance-schema-timing"/>.
     </para>

@@ -842,9 +842,9 @@
       </para>
 
 <programlisting>
-[ERROR] Native table 'performance_schema'.'EVENTS_WAITS_HISTORY'
+[ERROR] Native table 'performance_schema'.'events_waits_history'
 has the wrong structure
-[ERROR] Native table 'performance_schema'.'EVENTS_WAITS_HISTORY_LONG'
+[ERROR] Native table 'performance_schema'.'events_waits_history_long'
 has the wrong structure
 ...
 </programlisting>

@@ -862,7 +862,7 @@
   --performance_schema
                       Enable the performance schema.
   --performance_schema_events_waits_history_long_size=#
-                      Number of rows in EVENTS_WAITS_HISTORY_LONG.
+                      Number of rows in events_waits_history_long.
 ...
 </programlisting>
 

@@ -1055,10 +1055,10 @@
 +-------------------+
 | TABLE_NAME        |
 +-------------------+
-| SETUP_CONSUMERS   |
-| SETUP_INSTRUMENTS |
+| setup_consumers   |
+| setup_instruments |
 | SETUP_OBJECTS     |
-| SETUP_TIMERS      |
+| setup_timers      |
 +-------------------+
 </programlisting>
 

@@ -1074,11 +1074,11 @@
 
       <para>
         To see which event timer is selected, query the
-        <literal>SETUP_TIMERS</literal> tables:
+        <literal>setup_timers</literal> tables:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -1103,9 +1103,9 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_TIMERS SET TIMER_NAME = 'NANOSECOND';</userinput>
+mysql&gt; <userinput>UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND';</userinput>
 
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -1119,8 +1119,8 @@
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> and
-        <literal>SETUP_CONSUMERS</literal> tables list the instruments
+        The <literal>setup_instruments</literal> and
+        <literal>setup_consumers</literal> tables list the instruments
         for which events can be collected and the destination tables in
         which event information can be stored, respectively.
         <xref linkend="performance-schema-filtering"/>, discusses how

@@ -1158,12 +1158,12 @@
           <para>
             Instrumented code is the source for events and produces
             events to be collected. The
-            <literal>SETUP_INSTRUMENTS</literal> table lists the
+            <literal>setup_instruments</literal> table lists the
             instruments for which events can be collected:
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -1182,13 +1182,13 @@
         <listitem>
           <para>
             Performance Schema tables are the destinations for events
-            and consume events. The <literal>SETUP_CONSUMERS</literal>
+            and consume events. The <literal>setup_consumers</literal>
             table lists the destination tables in which event
             information can be stored:
           </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -1217,8 +1217,8 @@
       <para>
         Pre-filtering can be applied to either the producer or consumer
         stage of event processing by modifying the
-        <literal>SETUP_INSTRUMENTS</literal> or
-        <literal>SETUP_CONSUMERS</literal> table. An instrument or
+        <literal>setup_instruments</literal> or
+        <literal>setup_consumers</literal> table. An instrument or
         consumer can be enabled or disabled by setting its
         <literal>ENABLED</literal> value to <literal>YES</literal> or
         <literal>NO</literal>. An instrument can be configured whether

@@ -1286,7 +1286,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO';</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO';</userinput>
 </programlisting>
 
       <para>

@@ -1301,7 +1301,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/io/file/%';</userinput>
 </programlisting>
 

@@ -1310,7 +1310,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');</userinput>
 </programlisting>
 

@@ -1329,7 +1329,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;</userinput>
 </programlisting>
 

@@ -1338,7 +1338,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET ENABLED = 'NO'</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 

@@ -1348,7 +1348,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(ENABLED = 'YES', 'NO', 'YES')</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>

@@ -1370,7 +1370,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS SET TIMED = 'NO';</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments SET TIMED = 'NO';</userinput>
 </programlisting>
 
       <para>

@@ -1386,7 +1386,7 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 

@@ -1432,7 +1432,7 @@
 
 <programlisting>
 mysql&gt; <userinput>SELECT THREAD_ID, NUMBER_OF_BYTES</userinput>
-    -&gt; <userinput>FROM EVENTS_WAITS_HISTORY</userinput>
+    -&gt; <userinput>FROM events_waits_history</userinput>
     -&gt; <userinput>WHERE EVENT_NAME LIKE 'wait/io/file/%'</userinput>
     -&gt; <userinput>AND NUMBER_OF_BYTES IS NOT NULL;</userinput>
 +-----------+-----------------+

@@ -1453,11 +1453,11 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';</userinput>
 
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME = 'file_summary_by_instance';</userinput>
 </programlisting>
 

@@ -1467,11 +1467,11 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>UPDATE SETUP_INSTRUMENTS</userinput>
+mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/synch/mutex/%';</userinput>
 
-mysql&gt; <userinput>UPDATE SETUP_CONSUMERS</userinput>
+mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 

@@ -1502,9 +1502,9 @@
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT NAME FROM SETUP_INSTRUMENTS WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
+mysql&gt; <userinput>SELECT NAME FROM setup_instruments WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 
-mysql&gt; <userinput>SELECT NAME FROM SETUP_CONSUMERS WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
+mysql&gt; <userinput>SELECT NAME FROM setup_consumers WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 </programlisting>
 
     </section>

@@ -1711,7 +1711,7 @@
       <listitem>
         <para>
           No row for the instrument is inserted into the
-          <literal>SETUP_INSTRUMENTS</literal> table.
+          <literal>setup_instruments</literal> table.
         </para>
       </listitem>
 

@@ -1796,7 +1796,7 @@
       If an instrument is not lost, it is known to the Performance
       Schema, and is used when instrumenting instances. For example,
       <literal>wait/synch/mutex/sql/LOCK_delete</literal> is the name of
-      a mutex instrument in the <literal>SETUP_INSTRUMENTS</literal>
+      a mutex instrument in the <literal>setup_instruments</literal>
       table. This single instrument is used when creating in the code
       (in <literal>THD::LOCK_delete</literal>) however many instances of
       the mutex are needed as the server runs. In this case,

@@ -1858,15 +1858,15 @@
 ...
 *************************** 3. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_SIZE
+  Name: events_waits_history.ROW_SIZE
 Status: 76
 *************************** 4. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_COUNT
+  Name: events_waits_history.ROW_COUNT
 Status: 10000
 *************************** 5. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.MEMORY
+  Name: events_waits_history.MEMORY
 Status: 760000
 ...
 *************************** 57. row ***************************

@@ -1901,7 +1901,7 @@
     <para>
       Timers vary in precision and the amount of overhead they involve.
       To see what timers are available and their characteristics, check
-      the <literal>PERFORMANCE_TIMERS</literal> table:
+      the <literal>performance_timers</literal> table:
     </para>
 
 <!--

@@ -1912,7 +1912,7 @@
 -->
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM PERFORMANCE_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM performance_timers;</userinput>
 +-------------+-----------------+------------------+----------------+
 | TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
 +-------------+-----------------+------------------+----------------+

@@ -1958,20 +1958,20 @@
 
     <para>
       To see which timer is in effect or to change the timer, access the
-      <literal>SETUP_TIMERS</literal> table, which has a single row:
+      <literal>setup_timers</literal> table, which has a single row:
     </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+
 | wait | CYCLE      |
 +------+------------+
 
-mysql&gt; <userinput>UPDATE SETUP_TIMERS SET TIMER_NAME = 'MICROSECOND';</userinput>
+mysql&gt; <userinput>UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND';</userinput>
 
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+-------------+
 | NAME | TIMER_NAME  |
 +------+-------------+

@@ -2099,7 +2099,7 @@
     </para>
 
     <para>
-      The <literal>SETUP_INSTRUMENTS</literal> table has an
+      The <literal>setup_instruments</literal> table has an
       <literal>ENABLED</literal> column to indicate the instruments for
       which to collect events. The table also has a
       <literal>TIMED</literal> column to indicate which instruments are

@@ -2394,7 +2394,7 @@
       <listitem>
         <para>
           Current events table. The
-          <literal>EVENTS_WAITS_CURRENT</literal> table contains the
+          <literal>events_waits_current</literal> table contains the
           most recent event for each thread.
         </para>
       </listitem>

@@ -2402,10 +2402,10 @@
       <listitem>
         <para>
           History tables. These tables have the same structure as
-          <literal>EVENTS_WAITS_CURRENT</literal> but contain more rows.
-          The <literal>EVENTS_WAITS_HISTORY</literal> table contains the
+          <literal>events_waits_current</literal> but contain more rows.
+          The <literal>events_waits_history</literal> table contains the
           most recent 10 events per thread.
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> contains the most
+          <literal>events_waits_history_long</literal> contains the most
           recent 10,000 events.
         </para>
 

@@ -2476,20 +2476,20 @@
 +-------------------+
 | TABLE_NAME        |
 +-------------------+
-| SETUP_CONSUMERS   |
-| SETUP_INSTRUMENTS |
+| setup_consumers   |
+| setup_instruments |
 | SETUP_OBJECTS     |
-| SETUP_TIMERS      |
+| setup_timers      |
 +-------------------+
 </programlisting>
 
       <para>
-        The <literal>SETUP_CONSUMERS</literal> table lists destination
+        The <literal>setup_consumers</literal> table lists destination
         tables for event information:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_CONSUMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
 +----------------------------------------------+---------+
 | NAME                                         | ENABLED |
 +----------------------------------------------+---------+

@@ -2505,7 +2505,7 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_CONSUMERS</literal> table has these columns:
+        The <literal>setup_consumers</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2538,18 +2538,18 @@
       <para>
         Disabling the <literal>events_waits_current</literal> consumer
         disables everything else that depends on waits, such as the
-        <literal>EVENTS_WAITS_HISTORY</literal> and
-        <literal>EVENTS_WAITS_HISTORY_LONG</literal> tables, and all
+        <literal>events_waits_history</literal> and
+        <literal>events_waits_history_long</literal> tables, and all
         summary tables.
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> table lists classes of
+        The <literal>setup_instruments</literal> table lists classes of
         instrumented objects for which events can be collected:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_INSTRUMENTS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+
 | NAME                                                       | ENABLED | TIMED |
 +------------------------------------------------------------+---------+-------+

@@ -2571,7 +2571,7 @@
       </para>
 
       <para>
-        The <literal>SETUP_INSTRUMENTS</literal> table has these
+        The <literal>setup_instruments</literal> table has these
         columns:
       </para>
 

@@ -2635,12 +2635,12 @@
       </para>
 
       <para>
-        The <literal>SETUP_TIMERS</literal> table shows the currently
+        The <literal>setup_timers</literal> table shows the currently
         selected event timer:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM SETUP_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM setup_timers;</userinput>
 +------+------------+
 | NAME | TIMER_NAME |
 +------+------------+

@@ -2649,15 +2649,15 @@
 </programlisting>
 
       <para>
-        The <literal>SETUP_TIMERS.TIMER_NAME</literal> value can be
+        The <literal>setup_timers.TIMER_NAME</literal> value can be
         changed to select a different timer. The value can be any of the
-        <literal>PERFORMANCE_TIMERS.TIMER_NAME</literal> values. For an
+        <literal>performance_timers.TIMER_NAME</literal> values. For an
         explanation of how event timing occurs, see
         <xref linkend="performance-schema-timing"/>.
       </para>
 
       <para>
-        The <literal>SETUP_TIMERS</literal> table has these columns:
+        The <literal>setup_timers</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -2702,12 +2702,12 @@
 +----------------------+
 | TABLE_NAME           |
 +----------------------+
-| EVENTS_WAITS_CURRENT |
+| events_waits_current |
 +----------------------+
 </programlisting>
 
       <para>
-        The <literal>EVENTS_WAITS_CURRENT</literal> table contains a row
+        The <literal>events_waits_current</literal> table contains a row
         per thread showing the current status of each thread's most
         recent monitored event. When nesting events are implemented, it
         will be possible for a thread to have multiple events in

@@ -2721,7 +2721,7 @@
 
       <para>
         Of the tables that contain event rows,
-        <literal>EVENTS_WAITS_CURRENT</literal> is the most fundamental.
+        <literal>events_waits_current</literal> is the most fundamental.
         Other tables that contain event rows are logically derived from
         the current events. For example, the history tables are
         collections of the most recent events, up to a fixed number of

@@ -2729,7 +2729,7 @@
       </para>
 
       <para>
-        The <literal>EVENTS_WAITS_CURRENT</literal> table has these
+        The <literal>events_waits_current</literal> table has these
         columns:
       </para>
 

@@ -2756,7 +2756,7 @@
           <para>
             The name of the instrument from which the event was
             collected. This is a
-            <literal>SETUP_INSTRUMENTS.NAME</literal> value. Instrument
+            <literal>setup_instruments.NAME</literal> value. Instrument
             names have multiple parts and form a hierarchy, as discussed
             in <xref linkend="performance-schema-instrument-naming"/>.
           </para>

@@ -2976,14 +2976,14 @@
 +---------------------------+
 | TABLE_NAME                |
 +---------------------------+
-| EVENTS_WAITS_HISTORY      |
-| EVENTS_WAITS_HISTORY_LONG |
+| events_waits_history      |
+| events_waits_history_long |
 +---------------------------+
 </programlisting>
 
       <para>
-        The history tables, <literal>EVENTS_WAITS_HISTORY</literal> and
-        <literal>EVENTS_WAITS_HISTORY_LONG</literal>, contain the most
+        The history tables, <literal>events_waits_history</literal> and
+        <literal>events_waits_history_long</literal>, contain the most
         recent 10 events per thread and most recent 10,000 events,
         respectively. As new events are added to a history table, older
         events are discarded if the table is full. Events are not added

@@ -2997,7 +2997,7 @@
 
       <para>
         The history tables have the same structure as
-        <literal>EVENTS_WAITS_CURRENT</literal>. See
+        <literal>events_waits_current</literal>. See
         <xref linkend="performance-schema-current-tables"/>.
       </para>
 

@@ -3026,10 +3026,10 @@
 | TABLE_NAME                                   |
 +----------------------------------------------+
 | EVENTS_WAITS_SUMMARY_BY_EVENT_NAME           |
-| EVENTS_WAITS_SUMMARY_BY_INSTANCE             |
-| EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME |
-| FILE_SUMMARY_BY_EVENT_NAME                   |
-| FILE_SUMMARY_BY_INSTANCE                     |
+| events_waits_summary_by_instance             |
+| events_waits_summary_by_thread_by_event_name |
+| file_summary_by_event_name                   |
+| file_summary_by_instance                     |
 +----------------------------------------------+
 </programlisting>
 

@@ -3137,7 +3137,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_BY_INSTANCE</literal> has
+            <literal>events_waits_summary_by_instance</literal> has
             <literal>EVENT_NAME</literal> and
             <literal>OBJECT_INSTANCE_BEGIN</literal> columns. Each row
             summarizes events for a given instrument instance. If an

@@ -3150,7 +3150,7 @@
 
         <listitem>
           <para>
-            <literal>EVENTS_WAITS_SUMMARY_BY_THREAD_BY_EVENT_NAME</literal>
+            <literal>events_waits_summary_by_thread_by_event_name</literal>
             has <literal>THREAD_ID</literal> and
             <literal>EVENT_NAME</literal> columns. Each row summarizes
             events for a given thread and instrument.

@@ -3218,7 +3218,7 @@
 
         <listitem>
           <para>
-            <literal>FILE_SUMMARY_BY_EVENT_NAME</literal> has an
+            <literal>file_summary_by_event_name</literal> has an
             <literal>EVENT_NAME</literal> column. Each row summarizes
             events for a given instrument.
           </para>

@@ -3226,7 +3226,7 @@
 
         <listitem>
           <para>
-            <literal>FILE_SUMMARY_BY_INSTANCE</literal> has
+            <literal>file_summary_by_instance</literal> has
             <literal>FILE_NAME</literal> and
             <literal>EVENT_NAME</literal> columns. Each row summarizes
             events for a given file.

@@ -3286,10 +3286,10 @@
 +------------------+
 | TABLE_NAME       |
 +------------------+
-| COND_INSTANCES   |
-| FILE_INSTANCES   |
-| MUTEX_INSTANCES  |
-| RWLOCK_INSTANCES |
+| cond_instances   |
+| file_instances   |
+| mutex_instances  |
+| rwlock_instances |
 +------------------+
 </programlisting>
 

@@ -3310,7 +3310,7 @@
       </para>
 
       <para>
-        The <literal>COND_INSTANCES</literal> table has these columns:
+        The <literal>cond_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3339,16 +3339,16 @@
       </itemizedlist>
 
       <para>
-        The <literal>FILE_INSTANCES</literal> table lists all the files
+        The <literal>file_instances</literal> table lists all the files
         seen by the Performance Schema when executing file I/O
         instrumentation. If a file on disk has never been opened, it
-        will not be in <literal>FILE_INSTANCES</literal>. When a file is
+        will not be in <literal>file_instances</literal>. When a file is
         deleted from the disk, it is also removed from the
-        <literal>FILE_INSTANCES</literal> table.
+        <literal>file_instances</literal> table.
       </para>
 
       <para>
-        The <literal>FILE_INSTANCES</literal> table has these columns:
+        The <literal>file_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3390,7 +3390,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>MUTEX_INSTANCES</literal> table has these columns:
+        The <literal>mutex_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3431,7 +3431,7 @@
       </itemizedlist>
 
       <para>
-        The <literal>RWLOCK_INSTANCES</literal> table has these columns:
+        The <literal>rwlock_instances</literal> table has these columns:
       </para>
 
       <itemizedlist>

@@ -3490,8 +3490,8 @@
       </itemizedlist>
 
       <para>
-        The <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal> and
-        <literal>RWLOCK_INSTANCES.WRITE_LOCKED_BY_THREAD_ID</literal>
+        The <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal> and
+        <literal>rwlock_instances.WRITE_LOCKED_BY_THREAD_ID</literal>
         columns are extremely important for investigating performance
         bottlenecks or deadlocks. For examples of how to use them for
         this purpose, see <xref linkend="performance-schema-examples"/>

@@ -3504,12 +3504,12 @@
       <title>Performance Schema Miscellaneous Tables</title>
 
       <para>
-        The <literal>PERFORMANCE_TIMERS</literal> table shows which
+        The <literal>performance_timers</literal> table shows which
         event timers are available:
       </para>
 
 <programlisting>
-mysql&gt; <userinput>SELECT * FROM PERFORMANCE_TIMERS;</userinput>
+mysql&gt; <userinput>SELECT * FROM performance_timers;</userinput>
 +-------------+-----------------+------------------+----------------+
 | TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
 +-------------+-----------------+------------------+----------------+

@@ -3529,7 +3529,7 @@
       </para>
 
       <para>
-        The <literal>PERFORMANCE_TIMERS</literal> table has these
+        The <literal>performance_timers</literal> table has these
         columns:
       </para>
 

@@ -3750,7 +3750,7 @@
 
         <para>
           The number of rows in the
-          <literal>EVENTS_WAITS_HISTORY_LONG</literal> table.
+          <literal>events_waits_history_long</literal> table.
         </para>
       </listitem>
 

@@ -3770,7 +3770,7 @@
 
         <para>
           The number of rows per thread in the
-          <literal>EVENTS_WAITS_HISTORY</literal> table.
+          <literal>events_waits_history</literal> table.
         </para>
       </listitem>
 

@@ -4225,7 +4225,7 @@
 
         <para>
           At each iteration, the Performance Schema output, particularly
-          the <literal>EVENTS_WAITS_HISTORY_LONG</literal> table, will
+          the <literal>events_waits_history_long</literal> table, will
           contain less and less <quote>noise</quote> caused by
           nonsignificant instruments, and given that this table has a
           fixed size, will contain more and more data relevant to the

@@ -4287,8 +4287,8 @@
     </orderedlist>
 
     <para>
-      The <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal> and
-      <literal>RWLOCK_INSTANCES.WRITE_LOCKED_BY_THREAD_ID</literal>
+      The <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal> and
+      <literal>rwlock_instances.WRITE_LOCKED_BY_THREAD_ID</literal>
       columns are extremely important for investigating performance
       bottlenecks or deadlocks. This is made possible by Performance
       Schema instrumentation as follows:

@@ -4308,13 +4308,13 @@
         </para>
 
 <programlisting>
-SELECT * FROM EVENTS_WAITS_CURRENT WHERE THREAD_ID = <replaceable>thread_1</replaceable>;
+SELECT * FROM events_waits_current WHERE THREAD_ID = <replaceable>thread_1</replaceable>;
 </programlisting>
 
         <para>
           Say the query result identifies that the thread is waiting for
           mutex A, found in
-          <literal>EVENTS_WAITS_CURRENT.OBJECT_INSTANCE_BEGIN</literal>.
+          <literal>events_waits_current.OBJECT_INSTANCE_BEGIN</literal>.
         </para>
       </listitem>
 

@@ -4324,13 +4324,13 @@
         </para>
 
 <programlisting>
-SELECT * FROM MUTEX_INSTANCES WHERE OBJECT_INSTANCE_BEGIN = <replaceable>mutex_A</replaceable>;
+SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = <replaceable>mutex_A</replaceable>;
 </programlisting>
 
         <para>
           Say the query result identifies that it is thread 2 holding
           mutex A, as found in
-          <literal>MUTEX_INSTANCES.LOCKED_BY_THREAD_ID</literal>.
+          <literal>mutex_instances.LOCKED_BY_THREAD_ID</literal>.
         </para>
       </listitem>
 

@@ -4340,7 +4340,7 @@
         </para>
 
 <programlisting>
-SELECT * FROM EVENTS_WAITS_CURRENT WHERE THREAD_ID = <replaceable>thread_2</replaceable>;
+SELECT * FROM events_waits_current WHERE THREAD_ID = <replaceable>thread_2</replaceable>;
 </programlisting>
       </listitem>
 


Modified: trunk/refman-6.0/restrictions.xml
===================================================================
--- trunk/refman-6.0/restrictions.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-6.0/restrictions.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 646 bytes

@@ -1486,7 +1486,7 @@
 
     <para>
       The types of timers might vary per platform. The
-      <literal>PERFORMANCE_TIMERS</literal> table shows which event
+      <literal>performance_timers</literal> table shows which event
       timers are available. If the values in this table for a given
       timer name are <literal>NULL</literal>, that timer is not
       supported on your platform.


Modified: trunk/refman-6.0/sql-syntax-server-administration.xml
===================================================================
--- trunk/refman-6.0/sql-syntax-server-administration.xml	2010-12-07 19:11:09 UTC (rev 24304)
+++ trunk/refman-6.0/sql-syntax-server-administration.xml	2010-12-07 20:18:11 UTC (rev 24305)
Changed blocks: 3, Lines Added: 7, Lines Deleted: 7; 2273 bytes

@@ -6242,15 +6242,15 @@
 ...
 *************************** 3. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_SIZE
+  Name: events_waits_history.ROW_SIZE
 Status: 76
 *************************** 4. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.ROW_COUNT
+  Name: events_waits_history.ROW_COUNT
 Status: 10000
 *************************** 5. row ***************************
   Type: performance_schema
-  Name: EVENTS_WAITS_HISTORY.MEMORY
+  Name: events_waits_history.MEMORY
 Status: 760000
 ...
 *************************** 57. row ***************************

@@ -6277,8 +6277,8 @@
             Internal buffers that are exposed as a table in the
             <literal>performance_schema</literal> are named after the
             table. Examples:
-            <literal>EVENTS_WAITS_HISTORY.ROW_SIZE</literal>,
-            <literal>MUTEX_INSTANCES.ROW_COUNT</literal>.
+            <literal>events_waits_history.ROW_SIZE</literal>,
+            <literal>mutex_instances.ROW_COUNT</literal>.
           </para>
         </listitem>
 

@@ -6339,11 +6339,11 @@
         In some cases, there is a direct relationship between a
         configuration parameter and a <literal>SHOW ENGINE</literal>
         value. For example,
-        <literal>EVENTS_WAITS_HISTORY_LONG.ROW_COUNT</literal>
+        <literal>events_waits_history_long.ROW_COUNT</literal>
         corresponds to
         <literal role="sysvar">performance_schema_events_waits_history_long_size</literal>.
         In other cases, the relationship is more complex. For example,
-        <literal>EVENTS_WAITS_HISTORY.ROW_COUNT</literal> corresponds to
+        <literal>events_waits_history.ROW_COUNT</literal> corresponds to
         <literal role="sysvar">performance_schema_events_waits_history_size</literal>
         (the number of rows per thread) multiplied by
         <literal role="sysvar">performance_schema_max_thread_instances</literal>


Thread
svn commit - mysqldoc@docsrva: r24305 - in trunk: . dynamic-docs/changelog dynamic-docs/glossary innodb-1.1 innodb-plugin-1.1 refman-5.5 refman-5.6 re...paul.dubois7 Dec