List:Commits« Previous MessageNext Message »
From:paul.dubois Date:March 19 2011 4:11pm
Subject:svn commit - mysqldoc@oter02: r25450 - in trunk: . refman-5.5 refman-5.6 refman-6.0
View as plain text  
Author: pd221994
Date: 2011-03-19 17:11:58 +0100 (Sat, 19 Mar 2011)
New Revision: 25450

Log:
 r46064@dhcp-adc-twvpn-1-vpnpool-10-154-9-163:  paul | 2011-03-19 11:09:08 -0500
 P_S general revisions


Modified:
   svk:merge
   trunk/refman-5.5/performance-schema-core.xml
   trunk/refman-5.6/performance-schema-core.xml
   trunk/refman-6.0/performance-schema-core.xml

Property changes on: trunk
___________________________________________________________________

Modified: svk:merge
===================================================================


Changed blocks: 0, Lines Added: 0, Lines Deleted: 0; 1277 bytes


Modified: trunk/refman-5.5/performance-schema-core.xml
===================================================================
--- trunk/refman-5.5/performance-schema-core.xml	2011-03-19 16:11:53 UTC (rev 25449)
+++ trunk/refman-5.5/performance-schema-core.xml	2011-03-19 16:11:58 UTC (rev 25450)
Changed blocks: 5, Lines Added: 28, Lines Deleted: 26; 4366 bytes

@@ -1128,7 +1128,7 @@
 
   <section id="performance-schema-filtering">
 
-    <title>Event Collection Filtering</title>
+    <title>Event Filtering</title>
 
     <indexterm>
       <primary>Performance Schema</primary>

@@ -1189,7 +1189,7 @@
           Performance Schema tables are the destinations for events and
           consume events. The
           <literal role="ps">setup_consumers</literal> table lists the
-          types of consumers for which event information can be stored:
+          types of consumers to which event information can be sent:
         </para>
 
 <programlisting>

@@ -1220,12 +1220,12 @@
 
       <listitem>
         <para>
-          Pre-filtering is done by modifying Performance Schema
-          configuration so that only certain types of events are
-          collected from producers, and collected events are used to
-          update only certain consumers. This type of filtering is done
-          by Performance Schema and has a global effect that applies to
-          all users.
+          <emphasis role="bold">Pre-filtering.</emphasis> This is done
+          by modifying Performance Schema configuration so that only
+          certain types of events are collected from producers, and
+          collected events are used to update only certain consumers.
+          This type of filtering is done by Performance Schema and has a
+          global effect that applies to all users.
         </para>
 
         <para>

@@ -1272,12 +1272,12 @@
 
       <listitem>
         <para>
-          Post-filtering involves the use of <literal>WHERE</literal>
-          clauses when selecting information from Performance Schema
-          tables, to specify which of the available events you want to
-          see. This type of filtering is performed on a per-user basis
-          because individual users select which of the available events
-          are of interest.
+          <emphasis role="bold">Post-filtering.</emphasis> This involves
+          the use of <literal>WHERE</literal> clauses when selecting
+          information from Performance Schema tables, to specify which
+          of the available events you want to see. This type of
+          filtering is performed on a per-user basis because individual
+          users select which of the available events are of interest.
         </para>
 
         <para>

@@ -1467,21 +1467,23 @@
       </para>
 
       <para>
-        Changing which instruments are enabled or timed does not flush
-        the history tables. Events already collected remain in the
-        current-events and history tables until displaced by newer
-        events. If you disable instruments, you might need to wait a
-        while before events for them are displaced by newer events of
-        interest. Alternatively, use <literal role="stmt">TRUNCATE
-        TABLE</literal> to empty the history tables.
+        When you change which instruments are enabled or timed,
+        Performance Schema does not flush the history tables. Events
+        already collected remain in the current-events and history
+        tables until displaced by newer events. If you disable
+        instruments, you might need to wait a while before events for
+        them are displaced by newer events of interest. Alternatively,
+        use <literal role="stmt">TRUNCATE TABLE</literal> to empty the
+        history tables.
       </para>
 
       <para>
-        You might want to truncate the summary tables as well to clear
-        aggregate information for previously collected events. With
-        summary tables, the effect of <literal role="stmt">TRUNCATE
-        TABLE</literal> is to reset the summary columns to 0 or
-        <literal>NULL</literal>, not to remove rows.
+        After instrumentation changes, you might want to truncate the
+        summary tables as well to clear aggregate information for
+        previously collected events. With summary tables, the effect of
+        <literal role="stmt">TRUNCATE TABLE</literal> is to reset the
+        summary columns to 0 or <literal>NULL</literal>, not to remove
+        rows.
       </para>
 
       <para>


Modified: trunk/refman-5.6/performance-schema-core.xml
===================================================================
--- trunk/refman-5.6/performance-schema-core.xml	2011-03-19 16:11:53 UTC (rev 25449)
+++ trunk/refman-5.6/performance-schema-core.xml	2011-03-19 16:11:58 UTC (rev 25450)
Changed blocks: 19, Lines Added: 241, Lines Deleted: 92; 20402 bytes

@@ -1123,7 +1123,7 @@
 
   <section id="performance-schema-filtering">
 
-    <title>Event Collection Filtering</title>
+    <title>Event Filtering</title>
 
     <indexterm>
       <primary>Performance Schema</primary>

@@ -1192,7 +1192,7 @@
           Performance Schema tables are the destinations for events and
           consume events. The
           <literal role="ps">setup_consumers</literal> table lists the
-          types of consumers for which event information can be stored:
+          types of consumers to which event information can be sent:
         </para>
 
 <programlisting>

@@ -1220,12 +1220,12 @@
 
       <listitem>
         <para>
-          Pre-filtering is done by modifying Performance Schema
-          configuration so that only certain types of events are
-          collected from producers, and collected events are used to
-          update only certain consumers. This type of filtering is done
-          by Performance Schema and has a global effect that applies to
-          all users.
+          <emphasis role="bold">Pre-filtering.</emphasis> This is done
+          by modifying Performance Schema configuration so that only
+          certain types of events are collected from producers, and
+          collected events are used to update only certain consumers.
+          This type of filtering is done by Performance Schema and has a
+          global effect that applies to all users.
         </para>
 
         <para>

@@ -1272,12 +1272,12 @@
 
       <listitem>
         <para>
-          Post-filtering involves the use of <literal>WHERE</literal>
-          clauses when selecting information from Performance Schema
-          tables, to specify which of the available events you want to
-          see. This type of filtering is performed on a per-user basis
-          because individual users select which of the available events
-          are of interest.
+          <emphasis role="bold">Post-filtering.</emphasis> This involves
+          the use of <literal>WHERE</literal> clauses when selecting
+          information from Performance Schema tables, to specify which
+          of the available events you want to see. This type of
+          filtering is performed on a per-user basis because individual
+          users select which of the available events are of interest.
         </para>
 
         <para>

@@ -1362,10 +1362,6 @@
               <para>
                 The <literal role="ps">threads</literal> table indicates
                 whether monitoring is enabled for each server thread.
-                (This has no effect unless the
-                <literal>thread_instrumentation</literal> consumer in
-                <literal role="ps">setup_consumers</literal> table is
-                enabled.)
               </para>
             </listitem>
 

@@ -1389,15 +1385,35 @@
 
           <para>
             The <literal role="ps">setup_consumers</literal> table also
-            has an effect on event production. If a given event will not
-            be sent to any destination (that is, will not be consumed),
-            Performance Schema does not bother to produce it.
+            implicitly affects event production. If a given event will
+            not be sent to any destination (that is, will not be
+            consumed), Performance Schema does not produce it.
           </para>
         </listitem>
 
       </itemizedlist>
 
       <para>
+        When you change which instruments are enabled or timed,
+        Performance Schema does not flush the history tables. Events
+        already collected remain in the current-events and history
+        tables until displaced by newer events. If you disable
+        instruments, you might need to wait a while before events for
+        them are displaced by newer events of interest. Alternatively,
+        use <literal role="stmt">TRUNCATE TABLE</literal> to empty the
+        history tables.
+      </para>
+
+      <para>
+        After instrumentation changes, you might want to truncate the
+        summary tables as well to clear aggregate information for
+        previously collected events. With summary tables, the effect of
+        <literal role="stmt">TRUNCATE TABLE</literal> is to reset the
+        summary columns to 0 or <literal>NULL</literal>, not to remove
+        rows.
+      </para>
+
+      <para>
         The following sections describe how to use the tables that
         control how Performance Schema performs pre-filtering.
       </para>

@@ -1408,12 +1424,39 @@
 
         <para>
           The <literal role="ps">setup_instruments</literal> table lists
-          the available instruments. To control whether an instrument is
-          enabled, set its <literal>ENABLED</literal> column to
-          <literal>YES</literal> or <literal>NO</literal>. To configure
-          whether to collect timing information for an instrument, set
-          its <literal>TIMED</literal> value to <literal>YES</literal>
-          or <literal>NO</literal>. Setting the <literal>TIMED</literal>
+          the available instruments:
+        </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
++------------------------------------------------------------+---------+-------+
+| NAME                                                       | ENABLED | TIMED |
++------------------------------------------------------------+---------+-------+
+...
+| wait/synch/mutex/sql/LOCK_global_read_lock                 | YES     | YES   |
+| wait/synch/mutex/sql/LOCK_global_system_variables          | YES     | YES   |
+| wait/synch/mutex/sql/LOCK_lock_db                          | YES     | YES   |
+| wait/synch/mutex/sql/LOCK_manager                          | YES     | YES   |
+...
+| wait/synch/rwlock/sql/LOCK_grant                           | YES     | YES   |
+| wait/synch/rwlock/sql/LOGGER::LOCK_logger                  | YES     | YES   |
+| wait/synch/rwlock/sql/LOCK_sys_init_connect                | YES     | YES   |
+| wait/synch/rwlock/sql/LOCK_sys_init_slave                  | YES     | YES   |
+...
+| wait/io/file/sql/binlog                                    | YES     | YES   |
+| wait/io/file/sql/binlog_index                              | YES     | YES   |
+| wait/io/file/sql/casetest                                  | YES     | YES   |
+| wait/io/file/sql/dbopt                                     | YES     | YES   |
+...
+</programlisting>
+
+        <para>
+          To control whether an instrument is enabled, set its
+          <literal>ENABLED</literal> column to <literal>YES</literal> or
+          <literal>NO</literal>. To configure whether to collect timing
+          information for an instrument, set its
+          <literal>TIMED</literal> value to <literal>YES</literal> or
+          <literal>NO</literal>. Setting the <literal>TIMED</literal>
           column to <literal>NO</literal> affects Performance Schema
           table contents as described in
           <xref linkend="performance-schema-timing"/>.

@@ -1526,23 +1569,11 @@
         </itemizedlist>
 
         <para>
-          Changing which instruments are enabled or timed does not flush
-          the history tables. Events already collected remain in the
-          current-events and history tables until displaced by newer
-          events. If you disable instruments, you might need to wait a
-          while before events for them are displaced by newer events of
-          interest. Alternatively, use <literal role="stmt">TRUNCATE
-          TABLE</literal> to empty the history tables.
+          Modifications to the
+          <literal role="ps">setup_instruments</literal> table affect
+          monitoring immediately.
         </para>
 
-        <para>
-          You might want to truncate the summary tables as well to clear
-          aggregate information for previously collected events. With
-          summary tables, the effect of <literal role="stmt">TRUNCATE
-          TABLE</literal> is to reset the summary columns to 0 or
-          <literal>NULL</literal>, not to remove rows.
-        </para>
-
       </section>
 
       <section id="performance-schema-object-filtering">

@@ -1567,24 +1598,109 @@
 </programlisting>
 
         <para>
+          The <literal>OBJECT_SCHEMA</literal> and
+          <literal>OBJECT_NAME</literal> columns should name a specific
+          schema or table, or <literal>'%'</literal> to match any name.
+          Performance Schema tries to find more specific matches first,
+          <literal>'%'</literal> matches last.
+        </para>
+
+        <para>
           For table-related events, the contents of
           <literal role="ps">setup_objects</literal> are combined with
-          <literal role="ps">setup_instruments</literal>. That is,
-          enabled table instruments produce events only for those tables
-          that match the <literal>OBJECT_SCHEMA</literal> and
-          <literal>OBJECT_NAME</literal> columns of some row in
-          <literal role="ps">setup_objects</literal>.
+          <literal role="ps">setup_instruments</literal>:
         </para>
 
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              Enabled table instruments produce events only for those
+              tables that match the <literal>OBJECT_SCHEMA</literal> and
+              <literal>OBJECT_NAME</literal> columns of some row in
+              <literal role="ps">setup_objects</literal>.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              The <literal>TIMED</literal> values in the two tables are
+              combined, so that timing information is collected only
+              with both values are <literal>YES</literal>.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
         <para>
-          A value of <literal>'%'</literal> in the
-          <literal>OBJECT_SCHEMA</literal> or
-          <literal>OBJECT_NAME</literal> column means <quote>match any
-          name,</quote> so by default, monitoring is enabled for all
-          tables.
+          Because the <literal role="ps">setup_objects</literal> table
+          initially contains a row with <literal>'%'</literal> for both
+          <literal>OBJECT_SCHEMA</literal> and
+          <literal>OBJECT_NAME</literal>, by default, monitoring is
+          enabled for all tables.
         </para>
 
         <para>
+          Suppose that <literal role="ps">setup_objects</literal>
+          contains the following rows:
+        </para>
+
+<programlisting>
++-------------+---------------+-------------+-------+
+| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | TIMED |
++-------------+---------------+-------------+-------+
+| TABLE       | db1           | t1          | YES   |
+| TABLE       | db1           | t2          | NO    |
+| TABLE       | db2           | %           | YES   |
+| TABLE       | db3           | %           | NO    |
+| TABLE       | %             | %           | YES   |
++-------------+---------------+-------------+-------+
+</programlisting>
+
+        <para>
+          If a table-related instrument in
+          <literal role="ps">setup_instruments</literal> has a
+          <literal>TIMED</literal> value of <literal>NO</literal>, no
+          events for the instrument are timed. If the
+          <literal>TIMED</literal> value is <literal>YES</literal>,
+          events timing occurs as follows:
+        </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal>db1.t1</literal> is timed
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal>db1.t2</literal> is not timed
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal>db2.t3</literal> is timed
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal>db3.t4</literal> is not timed
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              <literal>db4.t5</literal> is timed
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
           If a persistent table and a temporary table have the same
           name, matching against
           <literal role="ps">setup_objects</literal> rows occurs the

@@ -1594,10 +1710,9 @@
         </para>
 
         <para>
-          Setting the <literal>TIMED</literal> column for objects to
-          <literal>NO</literal> affects Performance Schema table
-          contents as described in
-          <xref linkend="performance-schema-timing"/>.
+          Modifications to the
+          <literal role="ps">setup_objects</literal> table affect object
+          monitoring immediately.
         </para>
 
       </section>

@@ -1629,8 +1744,8 @@
 
           <listitem>
             <para>
-              Monitoring occurs only for those events produced from
-              instruments that are enabled, as specified in the
+              Monitoring occurs only for those thread events produced
+              from instruments that are enabled, as specified in the
               <literal role="ps">setup_instruments</literal> table.
             </para>
           </listitem>

@@ -1668,12 +1783,23 @@
 </programlisting>
 
         <para>
+          Performance Schema uses the <literal>HOST</literal> and
+          <literal>USER</literal> columns to match each new foreground
+          thread. The <literal>INSTRUMENTED</literal> value becomes
+          <literal>YES</literal> if any row matches.
+        </para>
+
+        <para>
           A value of <literal>'%'</literal> in the
           <literal>HOST</literal> or <literal>USER</literal> column
-          means <quote>match any name,</quote> so by default, monitoring
-          is enabled for all new foreground threads. If you want to
-          perform more limited matching, you must delete this row
-          because it matches any connection.
+          means <quote>match any name.</quote> Because the
+          <literal role="ps">setup_actors</literal> table initially
+          contains a row with <literal>'%'</literal> for both
+          <literal>HOST</literal> and <literal>USER</literal>, by
+          default, monitoring is enabled for all new foreground threads.
+          If you want to perform more limited matching such as to enable
+          monitoring only for some foreground threads, you must delete
+          this row because it matches any connection.
         </para>
 
         <para>

@@ -1683,48 +1809,54 @@
 
 <programlisting>
 DELETE FROM setup_actors;
-INSERT INTO setup_actors VALUES('joe','localhost','%');
-INSERT INTO setup_actors VALUES('sam','%','%');
-INSERT INTO setup_actors VALUES('bill','%.example.net','%');
 </programlisting>
 
         <para>
-          After the <literal role="stmt">DELETE</literal> statement,
-          <literal>setup_actors</literal> sis empty, there are no rows
-          that could match incoming connections, and any the
+          Now <literal>setup_actors</literal> is empty, there are no
+          rows that could match incoming connections, and any the
           <literal>INSTRUMENTED</literal> column for new foreground
           threads will be set to <literal>NO</literal>.
         </para>
 
         <para>
-          After the <literal role="stmt">INSERT</literal> statements,
-          connections match as follows:
+          Suppose that you further modify
+          <literal role="ps">setup_actors</literal>:
         </para>
 
+<programlisting>
+INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('localhost','joe','%');
+INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('%','sam','%');
+</programlisting>
+
+        <para>
+          Now connections match as follows:
+        </para>
+
         <itemizedlist>
 
           <listitem>
             <para>
               If <literal>joe</literal> connects from the local host,
-              there is a match to the first inserted row. If
-              <literal>joe</literal> connects from any other host, there
-              is no match.
+              there is a match to the first inserted row.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              If <literal>sam</literal> connects from any host, there is
-              a match to the second inserted row.
+              If <literal>joe</literal> connects from any other host,
+              there is no match.
             </para>
           </listitem>
 
           <listitem>
             <para>
-              If <literal>bill</literal> connects from any host in the
-              <literal>example.net</literal> domain, there is a match to
-              the third inserted row.
+              If <literal>sam</literal> connects from any host, there is
+              a match to the second inserted row.
             </para>
+
+            <para>
+              For any other connection, there is no match.
+            </para>
           </listitem>
 
         </itemizedlist>

@@ -1741,6 +1873,24 @@
         <title>Pre-Filtering by Consumer</title>
 
         <para>
+          The <literal>setup_consumers</literal> table lists the
+          available consumer types:
+        </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM setup_consumers;</userinput>
++---------------------------+---------+
+| NAME                      | ENABLED |
++---------------------------+---------+
+| events_waits_current      | YES     |
+| events_waits_history      | YES     |
+| events_waits_history_long | YES     |
+| global_instrumentation    | YES     |
+| thread_instrumentation    | YES     |
++---------------------------+---------+
+</programlisting>
+
+        <para>
           Modify the <literal role="ps">setup_consumers</literal> table
           to affect pre-filtering at the consumer stage and determine
           which destinations events are sent to. To enable or disable a

@@ -4139,9 +4289,8 @@
             </para>
 
             <para>
-              The host name. Permissible values are as in the host name
-              part of account names. See
-              <xref linkend="account-names"/>.
+              The host name. The value <literal>'%'</literal> means
+              <quote>any host.</quote>
             </para>
           </listitem>
 

@@ -4151,10 +4300,8 @@
             </para>
 
             <para>
-              The user name. Permissible values are as in the user name
-              part of account names, except that <quote>any user</quote>
-              is represented by <literal>'%'</literal> rather than the
-              empty string. See <xref linkend="account-names"/>.
+              The user name. The value <literal>'%'</literal> means
+              <quote>any user.</quote>
             </para>
           </listitem>
 

@@ -6526,15 +6673,15 @@
 <programlisting>
 mysql&gt; <userinput>SELECT * FROM threads\G</userinput>
 *************************** 1. row ***************************
-          THREAD_ID: 11
-               NAME: thread/innodb/io_handler_thread
+          THREAD_ID: 1
+               NAME: thread/sql/main
                TYPE: BACKGROUND
      PROCESSLIST_ID: NULL
    PROCESSLIST_USER: NULL
    PROCESSLIST_HOST: NULL
      PROCESSLIST_DB: NULL
 PROCESSLIST_COMMAND: NULL
-   PROCESSLIST_TIME: NULL
+   PROCESSLIST_TIME: 80284
   PROCESSLIST_STATE: NULL
    PROCESSLIST_INFO: NULL
    PARENT_THREAD_ID: NULL

@@ -6801,8 +6948,9 @@
                 <para>
                   For any thread, its <literal>INSTRUMENTED</literal>
                   value can be changed during the lifetime of the
-                  thread. This is the only table column that can be
-                  modified.
+                  thread. This is the only
+                  <literal role="ps">threads</literal> table column that
+                  can be modified.
                 </para>
               </listitem>
 

@@ -6831,8 +6979,9 @@
 
               <listitem>
                 <para>
-                  Monitoring occurs only for those events produced from
-                  instruments that are enabled, as specified in the
+                  Monitoring occurs only for those thread events
+                  produced from instruments that are enabled, as
+                  specified in the
                   <literal role="ps">setup_instruments</literal> table.
                 </para>
               </listitem>


Modified: trunk/refman-6.0/performance-schema-core.xml
===================================================================
--- trunk/refman-6.0/performance-schema-core.xml	2011-03-19 16:11:53 UTC (rev 25449)
+++ trunk/refman-6.0/performance-schema-core.xml	2011-03-19 16:11:58 UTC (rev 25450)
Changed blocks: 5, Lines Added: 28, Lines Deleted: 26; 4366 bytes

@@ -1151,7 +1151,7 @@
 
   <section id="performance-schema-filtering">
 
-    <title>Event Collection Filtering</title>
+    <title>Event Filtering</title>
 
     <indexterm>
       <primary>Performance Schema</primary>

@@ -1212,7 +1212,7 @@
           Performance Schema tables are the destinations for events and
           consume events. The
           <literal role="ps">setup_consumers</literal> table lists the
-          types of consumers for which event information can be stored:
+          types of consumers to which event information can be sent:
         </para>
 
 <programlisting>

@@ -1243,12 +1243,12 @@
 
       <listitem>
         <para>
-          Pre-filtering is done by modifying Performance Schema
-          configuration so that only certain types of events are
-          collected from producers, and collected events are used to
-          update only certain consumers. This type of filtering is done
-          by Performance Schema and has a global effect that applies to
-          all users.
+          <emphasis role="bold">Pre-filtering.</emphasis> This is done
+          by modifying Performance Schema configuration so that only
+          certain types of events are collected from producers, and
+          collected events are used to update only certain consumers.
+          This type of filtering is done by Performance Schema and has a
+          global effect that applies to all users.
         </para>
 
         <para>

@@ -1295,12 +1295,12 @@
 
       <listitem>
         <para>
-          Post-filtering involves the use of <literal>WHERE</literal>
-          clauses when selecting information from Performance Schema
-          tables, to specify which of the available events you want to
-          see. This type of filtering is performed on a per-user basis
-          because individual users select which of the available events
-          are of interest.
+          <emphasis role="bold">Post-filtering.</emphasis> This involves
+          the use of <literal>WHERE</literal> clauses when selecting
+          information from Performance Schema tables, to specify which
+          of the available events you want to see. This type of
+          filtering is performed on a per-user basis because individual
+          users select which of the available events are of interest.
         </para>
 
         <para>

@@ -1490,21 +1490,23 @@
       </para>
 
       <para>
-        Changing which instruments are enabled or timed does not flush
-        the history tables. Events already collected remain in the
-        current-events and history tables until displaced by newer
-        events. If you disable instruments, you might need to wait a
-        while before events for them are displaced by newer events of
-        interest. Alternatively, use <literal role="stmt">TRUNCATE
-        TABLE</literal> to empty the history tables.
+        When you change which instruments are enabled or timed,
+        Performance Schema does not flush the history tables. Events
+        already collected remain in the current-events and history
+        tables until displaced by newer events. If you disable
+        instruments, you might need to wait a while before events for
+        them are displaced by newer events of interest. Alternatively,
+        use <literal role="stmt">TRUNCATE TABLE</literal> to empty the
+        history tables.
       </para>
 
       <para>
-        You might want to truncate the summary tables as well to clear
-        aggregate information for previously collected events. With
-        summary tables, the effect of <literal role="stmt">TRUNCATE
-        TABLE</literal> is to reset the summary columns to 0 or
-        <literal>NULL</literal>, not to remove rows.
+        After instrumentation changes, you might want to truncate the
+        summary tables as well to clear aggregate information for
+        previously collected events. With summary tables, the effect of
+        <literal role="stmt">TRUNCATE TABLE</literal> is to reset the
+        summary columns to 0 or <literal>NULL</literal>, not to remove
+        rows.
       </para>
 
       <para>


Thread
svn commit - mysqldoc@oter02: r25450 - in trunk: . refman-5.5 refman-5.6 refman-6.0paul.dubois19 Mar