List:Commits« Previous MessageNext Message »
From:paul.dubois Date:March 15 2011 5:07pm
Subject:svn commit - mysqldoc@oter02: r25401 - in trunk: . refman-5.5 refman-5.6 refman-6.0
View as plain text  
Author: pd221994
Date: 2011-03-15 18:07:38 +0100 (Tue, 15 Mar 2011)
New Revision: 25401

Log:
 r45944@dhcp-adc-twvpn-1-vpnpool-10-154-12-131:  paul | 2011-03-15 11:17:25 -0500
 Promote filtering section


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-15 17:07:30 UTC (rev 25400)
+++ trunk/refman-5.5/performance-schema-core.xml	2011-03-15 17:07:38 UTC (rev 25401)
Changed blocks: 9, Lines Added: 246, Lines Deleted: 252; 23684 bytes

@@ -1124,39 +1124,41 @@
 
     </section>
 
-    <section id="performance-schema-filtering">
+  </section>
 
-      <title>Event Collection Filtering</title>
+  <section id="performance-schema-filtering">
 
-      <indexterm>
-        <primary>Performance Schema</primary>
-        <secondary>event filtering</secondary>
-      </indexterm>
+    <title>Event Collection Filtering</title>
 
-      <indexterm>
-        <primary>pre-filtering</primary>
-        <secondary>Performance Schema</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>Performance Schema</primary>
+      <secondary>event filtering</secondary>
+    </indexterm>
 
-      <indexterm>
-        <primary>post-filtering</primary>
-        <secondary>Performance Schema</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>pre-filtering</primary>
+      <secondary>Performance Schema</secondary>
+    </indexterm>
 
-      <para>
-        Events are processed in a producer/consumer fashion:
-      </para>
+    <indexterm>
+      <primary>post-filtering</primary>
+      <secondary>Performance Schema</secondary>
+    </indexterm>
 
-      <itemizedlist>
+    <para>
+      Events are processed in a producer/consumer fashion:
+    </para>
 
-        <listitem>
-          <para>
-            Instrumented code is the source for events and produces
-            events to be collected. The
-            <literal role="ps">setup_instruments</literal> table lists
-            the instruments for which events can be collected:
-          </para>
+    <itemizedlist>
 
+      <listitem>
+        <para>
+          Instrumented code is the source for events and produces events
+          to be collected. The
+          <literal role="ps">setup_instruments</literal> table lists the
+          instruments for which events can be collected:
+        </para>
+
 <programlisting>
 mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+

@@ -1179,15 +1181,15 @@
 | wait/io/file/sql/dbopt                                     | YES     | YES   |
 ...
 </programlisting>
-        </listitem>
+      </listitem>
 
-        <listitem>
-          <para>
-            Performance Schema tables are the destinations for events
-            and consume events. The
-            <literal role="ps">setup_consumers</literal> table lists the
-            destination tables in which event information can be stored:
-          </para>
+      <listitem>
+        <para>
+          Performance Schema tables are the destinations for events and
+          consume events. The
+          <literal role="ps">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>

@@ -1204,50 +1206,18 @@
 | file_summary_by_instance                     | YES     |
 +----------------------------------------------+---------+
 </programlisting>
-        </listitem>
+      </listitem>
 
-      </itemizedlist>
+    </itemizedlist>
 
-      <para>
-        Filtering can be done at different stages of performance
-        monitoring:
-      </para>
+    <para>
+      Filtering can be done at different stages of performance
+      monitoring:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <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.
-          </para>
-        </listitem>
-
-        <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.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-      <para>
-        The following sections provide more detail about each type of
-        filtering.
-      </para>
-
-      <section id="performance-schema-pre-filtering">
-
-        <title>Event Pre-Filtering</title>
-
+      <listitem>
         <para>
           Pre-filtering is done by modifying Performance Schema
           configuration so that only certain types of events are

@@ -1256,130 +1226,161 @@
           by Performance Schema and has a global effect that applies to
           all users.
         </para>
+      </listitem>
 
+      <listitem>
         <para>
-          Pre-filtering can be applied to either the producer or
-          consumer stage of event processing by modifying the
-          <literal role="ps">setup_instruments</literal> or
-          <literal role="ps">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 to collect timing information by setting its
-          <literal>TIMED</literal> value to <literal>YES</literal> or
-          <literal>NO</literal>.
+          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.
         </para>
+      </listitem>
 
-        <para>
-          Reasons to use pre-filtering include the following:
-        </para>
+    </itemizedlist>
 
-        <itemizedlist>
+    <para>
+      The following sections provide more detail about each type of
+      filtering.
+    </para>
 
-          <listitem>
-            <para>
-              Pre-filtering reduces overhead. The overhead should be
-              minimal even with all instruments enabled, but perhaps you
-              want to reduce it further. Or you do not care about timing
-              events and want to disable the timing code to eliminate
-              timing overhead.
-            </para>
-          </listitem>
+    <section id="performance-schema-pre-filtering">
 
-          <listitem>
-            <para>
-              You do not want to fill up the current-events or history
-              tables with events in which you have no interest.
-              Pre-filtering leaves more <quote>room</quote> in these
-              tables for instances of rows for enabled instrument types.
-              If you enable only file instruments with pre-filtering, no
-              rows are collected for nonfile instruments. With
-              post-filtering, nonfile events are collected, leaving
-              fewer rows for file events.
-            </para>
-          </listitem>
+      <title>Event Pre-Filtering</title>
 
-          <listitem>
-            <para>
-              You do not care about maintaining some kinds of event
-              tables. If you disable a consumer, the server does not
-              spend time maintaining it. For example, if you do not care
-              about aggregated event information, you can disable the
-              summary table consumers to improve performance.
-            </para>
-          </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.
+      </para>
 
-        </itemizedlist>
+      <para>
+        Pre-filtering can be applied to either the producer or consumer
+        stage of event processing by modifying the
+        <literal role="ps">setup_instruments</literal> or
+        <literal role="ps">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
+        to collect timing information by setting its
+        <literal>TIMED</literal> value to <literal>YES</literal> or
+        <literal>NO</literal>.
+      </para>
 
-        <para>
-          Example pre-filtering operations:
-        </para>
+      <para>
+        Reasons to use pre-filtering include the following:
+      </para>
 
-        <para>
-          Disable all instruments:
-        </para>
+      <itemizedlist>
 
+        <listitem>
+          <para>
+            Pre-filtering reduces overhead. The overhead should be
+            minimal even with all instruments enabled, but perhaps you
+            want to reduce it further. Or you do not care about timing
+            events and want to disable the timing code to eliminate
+            timing overhead.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            You do not want to fill up the current-events or history
+            tables with events in which you have no interest.
+            Pre-filtering leaves more <quote>room</quote> in these
+            tables for instances of rows for enabled instrument types.
+            If you enable only file instruments with pre-filtering, no
+            rows are collected for nonfile instruments. With
+            post-filtering, nonfile events are collected, leaving fewer
+            rows for file events.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            You do not care about maintaining some kinds of event
+            tables. If you disable a consumer, the server does not spend
+            time maintaining it. For example, if you do not care about
+            aggregated event information, you can disable the summary
+            table consumers to improve performance.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
+      <para>
+        Example pre-filtering operations:
+      </para>
+
+      <para>
+        Disable all instruments:
+      </para>
+
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO';</userinput>
 </programlisting>
 
-        <para>
-          Now no events will be collected. This change, like other
-          pre-filtering operations, affects other users as well, even if
-          they want to see event information.
-        </para>
+      <para>
+        Now no events will be collected. This change, like other
+        pre-filtering operations, affects other users as well, even if
+        they want to see event information.
+      </para>
 
-        <para>
-          Disable all file instruments, adding them to the current set
-          of disabled instruments:
-        </para>
+      <para>
+        Disable all file instruments, adding them to the current set of
+        disabled instruments:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/io/file/%';</userinput>
 </programlisting>
 
-        <para>
-          Disable only file instruments, enable all other instruments:
-        </para>
+      <para>
+        Disable only file instruments, enable all other instruments:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');</userinput>
 </programlisting>
 
-        <para>
-          The preceding queries use the
-          <literal role="op">LIKE</literal> operator and the pattern
-          <literal>'wait/io/file/%'</literal> to match all instrument
-          names that begin with <literal>'wait/io/file/</literal>.
-          Additional information about specifying patterns to select
-          instruments is given later in this section.
-        </para>
+      <para>
+        The preceding queries use the <literal role="op">LIKE</literal>
+        operator and the pattern <literal>'wait/io/file/%'</literal> to
+        match all instrument names that begin with
+        <literal>'wait/io/file/</literal>. Additional information about
+        specifying patterns to select instruments is given later in this
+        section.
+      </para>
 
-        <para>
-          Enable all but those instruments in the
-          <literal>mysys</literal> library:
-        </para>
+      <para>
+        Enable all but those instruments in the <literal>mysys</literal>
+        library:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;</userinput>
 </programlisting>
 
-        <para>
-          Disable a specific instrument:
-        </para>
+      <para>
+        Disable a specific instrument:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 
-        <para>
-          To toggle the state of an instrument, <quote>flip</quote> its
-          <literal>ENABLED</literal> value:
-        </para>
+      <para>
+        To toggle the state of an instrument, <quote>flip</quote> its
+        <literal>ENABLED</literal> value:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1387,95 +1388,91 @@
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 
-        <para>
-          Changing which instruments are enabled does not flush the
-          history tables. Events already collected remain in the
-          current-events, history, and summary 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. You might want to truncate the summary tables
-          as well to clear aggregate information for previously
-          collected events. With summary tables, the effect is to reset
-          the summary columns to 0 or <literal>NULL</literal>, not to
-          remove rows.
-        </para>
+      <para>
+        Changing which instruments are enabled does not flush the
+        history tables. Events already collected remain in the
+        current-events, history, and summary 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. You might want to
+        truncate the summary tables as well to clear aggregate
+        information for previously collected events. With summary
+        tables, the effect is to reset the summary columns to 0 or
+        <literal>NULL</literal>, not to remove rows.
+      </para>
 
-        <para>
-          Disable timing for all events:
-        </para>
+      <para>
+        Disable timing for all events:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET TIMED = 'NO';</userinput>
 </programlisting>
 
-        <para>
-          Setting the <literal>TIMED</literal> column for instruments to
-          <literal>NO</literal> affects Performance Schema table
-          contents as described in
-          <xref linkend="performance-schema-timing"/>.
-        </para>
+      <para>
+        Setting the <literal>TIMED</literal> column for instruments to
+        <literal>NO</literal> affects Performance Schema table contents
+        as described in <xref linkend="performance-schema-timing"/>.
+      </para>
 
-        <para>
-          If you disable a consumer, the server does not spend time
-          maintaining it. For example, you can disable the summary table
-          consumers if you do not care about aggregated event
-          information:
-        </para>
+      <para>
+        If you disable a consumer, the server does not spend time
+        maintaining it. For example, you can disable the summary table
+        consumers if you do not care about aggregated event information:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 
-      </section>
+    </section>
 
-      <section id="performance-schema-post-filtering">
+    <section id="performance-schema-post-filtering">
 
-        <title>Event Post-Filtering</title>
+      <title>Event Post-Filtering</title>
 
-        <para>
-          Pre-filtering limits which event information is collected and
-          is independent of any particular user. By contrast,
-          post-filtering is performed by individual users and is
-          performed by use of appropriate <literal>WHERE</literal>
-          clauses that restrict what event information to select from
-          the information available after pre-filtering has been
-          applied.
-        </para>
+      <para>
+        Pre-filtering limits which event information is collected and is
+        independent of any particular user. By contrast, post-filtering
+        is performed by individual users and is performed by use of
+        appropriate <literal>WHERE</literal> clauses that restrict what
+        event information to select from the information available after
+        pre-filtering has been applied.
+      </para>
 
-        <para>
-          Reasons to use post-filtering include the following:
-        </para>
+      <para>
+        Reasons to use post-filtering include the following:
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              To avoid making decisions for individual users about which
-              event information is of interest.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            To avoid making decisions for individual users about which
+            event information is of interest.
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              To use Performance Schema to investigate a performance
-              issue when the restrictions to impose using pre-filtering
-              are not known in advance.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            To use Performance Schema to investigate a performance issue
+            when the restrictions to impose using pre-filtering are not
+            known in advance.
+          </para>
+        </listitem>
 
-        </itemizedlist>
+      </itemizedlist>
 
-        <para>
-          In <xref linkend="performance-schema-pre-filtering"/>, an
-          example showed how to pre-filter for file instruments. If the
-          event tables contain both file and nonfile information,
-          post-filtering is another way to see information only for file
-          events. Add a <literal>WHERE</literal> clause to queries to
-          restrict event selection appropriately:
-        </para>
+      <para>
+        In <xref linkend="performance-schema-pre-filtering"/>, an
+        example showed how to pre-filter for file instruments. If the
+        event tables contain both file and nonfile information,
+        post-filtering is another way to see information only for file
+        events. Add a <literal>WHERE</literal> clause to queries to
+        restrict event selection appropriately:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT THREAD_ID, NUMBER_OF_BYTES</userinput>

@@ -1493,11 +1490,11 @@
 +-----------+-----------------+
 </programlisting>
 
-        <para>
-          Names given for filtering operations can be as specific or
-          general as required. To indicate a single instrument or
-          consumer, specify its name in full:
-        </para>
+      <para>
+        Names given for filtering operations can be as specific or
+        general as required. To indicate a single instrument or
+        consumer, specify its name in full:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1508,10 +1505,10 @@
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME = 'file_summary_by_instance';</userinput>
 </programlisting>
 
-        <para>
-          To specify a group of instruments or consumers, use a pattern
-          that matches the group members:
-        </para>
+      <para>
+        To specify a group of instruments or consumers, use a pattern
+        that matches the group members:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1522,31 +1519,30 @@
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 
-        <para>
-          If you use a pattern, it should be chosen so that it matches
-          all the items of interest and no others. For example, to
-          select all file I/O instruments, it is better to use a pattern
-          that includes the entire instrument name prefix:
-        </para>
+      <para>
+        If you use a pattern, it should be chosen so that it matches all
+        the items of interest and no others. For example, to select all
+        file I/O instruments, it is better to use a pattern that
+        includes the entire instrument name prefix:
+      </para>
 
 <programlisting>
 ... WHERE NAME LIKE 'wait/io/file/%';
 </programlisting>
 
-        <para>
-          A pattern of <literal>'%/file/%'</literal> will match other
-          instruments that have a component of
-          <literal>'/file/'</literal> anywhere in the name. Even less
-          suitable is the pattern <literal>'%file%'</literal> because it
-          will match instruments with <literal>'file'</literal> anywhere
-          in the name, such as
-          <literal>wait/synch/mutex/sql/LOCK_des_key_file</literal>.
-        </para>
+      <para>
+        A pattern of <literal>'%/file/%'</literal> will match other
+        instruments that have a component of <literal>'/file/'</literal>
+        anywhere in the name. Even less suitable is the pattern
+        <literal>'%file%'</literal> because it will match instruments
+        with <literal>'file'</literal> anywhere in the name, such as
+        <literal>wait/synch/mutex/sql/LOCK_des_key_file</literal>.
+      </para>
 
-        <para>
-          To check which instrument or consumer names a pattern matches,
-          perform a simple test:
-        </para>
+      <para>
+        To check which instrument or consumer names a pattern matches,
+        perform a simple test:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT NAME FROM setup_instruments WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>

@@ -1554,8 +1550,6 @@
 mysql&gt; <userinput>SELECT NAME FROM setup_consumers WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 </programlisting>
 
-      </section>
-
     </section>
 
   </section>


Modified: trunk/refman-5.6/performance-schema-core.xml
===================================================================
--- trunk/refman-5.6/performance-schema-core.xml	2011-03-15 17:07:30 UTC (rev 25400)
+++ trunk/refman-5.6/performance-schema-core.xml	2011-03-15 17:07:38 UTC (rev 25401)
Changed blocks: 9, Lines Added: 251, Lines Deleted: 257; 24087 bytes

@@ -1119,39 +1119,41 @@
 
     </section>
 
-    <section id="performance-schema-filtering">
+  </section>
 
-      <title>Event Collection Filtering</title>
+  <section id="performance-schema-filtering">
 
-      <indexterm>
-        <primary>Performance Schema</primary>
-        <secondary>event filtering</secondary>
-      </indexterm>
+    <title>Event Collection Filtering</title>
 
-      <indexterm>
-        <primary>pre-filtering</primary>
-        <secondary>Performance Schema</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>Performance Schema</primary>
+      <secondary>event filtering</secondary>
+    </indexterm>
 
-      <indexterm>
-        <primary>post-filtering</primary>
-        <secondary>Performance Schema</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>pre-filtering</primary>
+      <secondary>Performance Schema</secondary>
+    </indexterm>
 
-      <para>
-        Events are processed in a producer/consumer fashion:
-      </para>
+    <indexterm>
+      <primary>post-filtering</primary>
+      <secondary>Performance Schema</secondary>
+    </indexterm>
 
-      <itemizedlist>
+    <para>
+      Events are processed in a producer/consumer fashion:
+    </para>
 
-        <listitem>
-          <para>
-            Instrumented code is the source for events and produces
-            events to be collected. The
-            <literal role="ps">setup_instruments</literal> table lists
-            the instruments for which events can be collected:
-          </para>
+    <itemizedlist>
 
+      <listitem>
+        <para>
+          Instrumented code is the source for events and produces events
+          to be collected. The
+          <literal role="ps">setup_instruments</literal> table lists the
+          instruments for which events can be collected:
+        </para>
+
 <programlisting>
 mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+

@@ -1174,15 +1176,15 @@
 | wait/io/file/sql/dbopt                                     | YES     | YES   |
 ...
 </programlisting>
-        </listitem>
+      </listitem>
 
-        <listitem>
-          <para>
-            Performance Schema tables are the destinations for events
-            and consume events. The
-            <literal role="ps">setup_consumers</literal> table lists the
-            destination tables in which event information can be stored:
-          </para>
+      <listitem>
+        <para>
+          Performance Schema tables are the destinations for events and
+          consume events. The
+          <literal role="ps">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>

@@ -1196,50 +1198,18 @@
 | thread_instrumentation    | YES     |
 +---------------------------+---------+
 </programlisting>
-        </listitem>
+      </listitem>
 
-      </itemizedlist>
+    </itemizedlist>
 
-      <para>
-        Filtering can be done at different stages of performance
-        monitoring:
-      </para>
+    <para>
+      Filtering can be done at different stages of performance
+      monitoring:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <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.
-          </para>
-        </listitem>
-
-        <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.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-      <para>
-        The following sections provide more detail about each type of
-        filtering.
-      </para>
-
-      <section id="performance-schema-pre-filtering">
-
-        <title>Event Pre-Filtering</title>
-
+      <listitem>
         <para>
           Pre-filtering is done by modifying Performance Schema
           configuration so that only certain types of events are

@@ -1248,136 +1218,167 @@
           by Performance Schema and has a global effect that applies to
           all users.
         </para>
+      </listitem>
 
+      <listitem>
         <para>
-          Pre-filtering can be applied to either the producer or
-          consumer stage of event processing by modifying the
-          <literal role="ps">setup_instruments</literal> or
-          <literal role="ps">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 to collect timing information by setting its
-          <literal>TIMED</literal> value to <literal>YES</literal> or
-          <literal>NO</literal>.
+          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.
         </para>
+      </listitem>
 
-        <para>
-          For detailed information about the effect of enabling
-          different consumers, see
-          <xref linkend="performance-schema-consumer-configuration"/>.
-        </para>
+    </itemizedlist>
 
-        <para>
-          Reasons to use pre-filtering include the following:
-        </para>
+    <para>
+      The following sections provide more detail about each type of
+      filtering.
+    </para>
 
-        <itemizedlist>
+    <section id="performance-schema-pre-filtering">
 
-          <listitem>
-            <para>
-              Pre-filtering reduces overhead. The overhead should be
-              minimal even with all instruments enabled, but perhaps you
-              want to reduce it further. Or you do not care about timing
-              events and want to disable the timing code to eliminate
-              timing overhead.
-            </para>
-          </listitem>
+      <title>Event Pre-Filtering</title>
 
-          <listitem>
-            <para>
-              You do not want to fill up the current-events or history
-              tables with events in which you have no interest.
-              Pre-filtering leaves more <quote>room</quote> in these
-              tables for instances of rows for enabled instrument types.
-              If you enable only file instruments with pre-filtering, no
-              rows are collected for nonfile instruments. With
-              post-filtering, nonfile events are collected, leaving
-              fewer rows for file events.
-            </para>
-          </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.
+      </para>
 
-          <listitem>
-            <para>
-              You do not care about maintaining some kinds of event
-              tables. If you disable a consumer, the server does not
-              spend time maintaining it. For example, if you do not care
-              about aggregated event information, you can disable the
-              summary table consumers to improve performance.
-            </para>
-          </listitem>
+      <para>
+        Pre-filtering can be applied to either the producer or consumer
+        stage of event processing by modifying the
+        <literal role="ps">setup_instruments</literal> or
+        <literal role="ps">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
+        to collect timing information by setting its
+        <literal>TIMED</literal> value to <literal>YES</literal> or
+        <literal>NO</literal>.
+      </para>
 
-        </itemizedlist>
+      <para>
+        For detailed information about the effect of enabling different
+        consumers, see
+        <xref linkend="performance-schema-consumer-configuration"/>.
+      </para>
 
-        <para>
-          Example pre-filtering operations:
-        </para>
+      <para>
+        Reasons to use pre-filtering include the following:
+      </para>
 
-        <para>
-          Disable all instruments:
-        </para>
+      <itemizedlist>
 
+        <listitem>
+          <para>
+            Pre-filtering reduces overhead. The overhead should be
+            minimal even with all instruments enabled, but perhaps you
+            want to reduce it further. Or you do not care about timing
+            events and want to disable the timing code to eliminate
+            timing overhead.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            You do not want to fill up the current-events or history
+            tables with events in which you have no interest.
+            Pre-filtering leaves more <quote>room</quote> in these
+            tables for instances of rows for enabled instrument types.
+            If you enable only file instruments with pre-filtering, no
+            rows are collected for nonfile instruments. With
+            post-filtering, nonfile events are collected, leaving fewer
+            rows for file events.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            You do not care about maintaining some kinds of event
+            tables. If you disable a consumer, the server does not spend
+            time maintaining it. For example, if you do not care about
+            aggregated event information, you can disable the summary
+            table consumers to improve performance.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
+      <para>
+        Example pre-filtering operations:
+      </para>
+
+      <para>
+        Disable all instruments:
+      </para>
+
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO';</userinput>
 </programlisting>
 
-        <para>
-          Now no events will be collected. This change, like other
-          pre-filtering operations, affects other users as well, even if
-          they want to see event information.
-        </para>
+      <para>
+        Now no events will be collected. This change, like other
+        pre-filtering operations, affects other users as well, even if
+        they want to see event information.
+      </para>
 
-        <para>
-          Disable all file instruments, adding them to the current set
-          of disabled instruments:
-        </para>
+      <para>
+        Disable all file instruments, adding them to the current set of
+        disabled instruments:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/io/file/%';</userinput>
 </programlisting>
 
-        <para>
-          Disable only file instruments, enable all other instruments:
-        </para>
+      <para>
+        Disable only file instruments, enable all other instruments:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');</userinput>
 </programlisting>
 
-        <para>
-          The preceding queries use the
-          <literal role="op">LIKE</literal> operator and the pattern
-          <literal>'wait/io/file/%'</literal> to match all instrument
-          names that begin with <literal>'wait/io/file/</literal>.
-          Additional information about specifying patterns to select
-          instruments is given later in this section.
-        </para>
+      <para>
+        The preceding queries use the <literal role="op">LIKE</literal>
+        operator and the pattern <literal>'wait/io/file/%'</literal> to
+        match all instrument names that begin with
+        <literal>'wait/io/file/</literal>. Additional information about
+        specifying patterns to select instruments is given later in this
+        section.
+      </para>
 
-        <para>
-          Enable all but those instruments in the
-          <literal>mysys</literal> library:
-        </para>
+      <para>
+        Enable all but those instruments in the <literal>mysys</literal>
+        library:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;</userinput>
 </programlisting>
 
-        <para>
-          Disable a specific instrument:
-        </para>
+      <para>
+        Disable a specific instrument:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 
-        <para>
-          To toggle the state of an instrument, <quote>flip</quote> its
-          <literal>ENABLED</literal> value:
-        </para>
+      <para>
+        To toggle the state of an instrument, <quote>flip</quote> its
+        <literal>ENABLED</literal> value:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1385,95 +1386,91 @@
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 
-        <para>
-          Changing which instruments are enabled does not flush the
-          history tables. Events already collected remain in the
-          current-events, history, and summary 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. You might want to truncate the summary tables
-          as well to clear aggregate information for previously
-          collected events. With summary tables, the effect is to reset
-          the summary columns to 0 or <literal>NULL</literal>, not to
-          remove rows.
-        </para>
+      <para>
+        Changing which instruments are enabled does not flush the
+        history tables. Events already collected remain in the
+        current-events, history, and summary 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. You might want to
+        truncate the summary tables as well to clear aggregate
+        information for previously collected events. With summary
+        tables, the effect is to reset the summary columns to 0 or
+        <literal>NULL</literal>, not to remove rows.
+      </para>
 
-        <para>
-          Disable timing for all events:
-        </para>
+      <para>
+        Disable timing for all events:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET TIMED = 'NO';</userinput>
 </programlisting>
 
-        <para>
-          Setting the <literal>TIMED</literal> column for instruments to
-          <literal>NO</literal> affects Performance Schema table
-          contents as described in
-          <xref linkend="performance-schema-timing"/>.
-        </para>
+      <para>
+        Setting the <literal>TIMED</literal> column for instruments to
+        <literal>NO</literal> affects Performance Schema table contents
+        as described in <xref linkend="performance-schema-timing"/>.
+      </para>
 
-        <para>
-          If you disable a consumer, the server does not spend time
-          maintaining it. For example, you can disable the summary table
-          consumers if you do not care about aggregated event
-          information:
-        </para>
+      <para>
+        If you disable a consumer, the server does not spend time
+        maintaining it. For example, you can disable the summary table
+        consumers if you do not care about aggregated event information:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 
-      </section>
+    </section>
 
-      <section id="performance-schema-post-filtering">
+    <section id="performance-schema-post-filtering">
 
-        <title>Event Post-Filtering</title>
+      <title>Event Post-Filtering</title>
 
-        <para>
-          Pre-filtering limits which event information is collected and
-          is independent of any particular user. By contrast,
-          post-filtering is performed by individual users and is
-          performed by use of appropriate <literal>WHERE</literal>
-          clauses that restrict what event information to select from
-          the information available after pre-filtering has been
-          applied.
-        </para>
+      <para>
+        Pre-filtering limits which event information is collected and is
+        independent of any particular user. By contrast, post-filtering
+        is performed by individual users and is performed by use of
+        appropriate <literal>WHERE</literal> clauses that restrict what
+        event information to select from the information available after
+        pre-filtering has been applied.
+      </para>
 
-        <para>
-          Reasons to use post-filtering include the following:
-        </para>
+      <para>
+        Reasons to use post-filtering include the following:
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              To avoid making decisions for individual users about which
-              event information is of interest.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            To avoid making decisions for individual users about which
+            event information is of interest.
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              To use Performance Schema to investigate a performance
-              issue when the restrictions to impose using pre-filtering
-              are not known in advance.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            To use Performance Schema to investigate a performance issue
+            when the restrictions to impose using pre-filtering are not
+            known in advance.
+          </para>
+        </listitem>
 
-        </itemizedlist>
+      </itemizedlist>
 
-        <para>
-          In <xref linkend="performance-schema-pre-filtering"/>, an
-          example showed how to pre-filter for file instruments. If the
-          event tables contain both file and nonfile information,
-          post-filtering is another way to see information only for file
-          events. Add a <literal>WHERE</literal> clause to queries to
-          restrict event selection appropriately:
-        </para>
+      <para>
+        In <xref linkend="performance-schema-pre-filtering"/>, an
+        example showed how to pre-filter for file instruments. If the
+        event tables contain both file and nonfile information,
+        post-filtering is another way to see information only for file
+        events. Add a <literal>WHERE</literal> clause to queries to
+        restrict event selection appropriately:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT THREAD_ID, NUMBER_OF_BYTES</userinput>

@@ -1491,11 +1488,11 @@
 +-----------+-----------------+
 </programlisting>
 
-        <para>
-          Names given for filtering operations can be as specific or
-          general as required. To indicate a single instrument or
-          consumer, specify its name in full:
-        </para>
+      <para>
+        Names given for filtering operations can be as specific or
+        general as required. To indicate a single instrument or
+        consumer, specify its name in full:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1506,10 +1503,10 @@
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME = 'file_summary_by_instance';</userinput>
 </programlisting>
 
-        <para>
-          To specify a group of instruments or consumers, use a pattern
-          that matches the group members:
-        </para>
+      <para>
+        To specify a group of instruments or consumers, use a pattern
+        that matches the group members:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1520,31 +1517,30 @@
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 
-        <para>
-          If you use a pattern, it should be chosen so that it matches
-          all the items of interest and no others. For example, to
-          select all file I/O instruments, it is better to use a pattern
-          that includes the entire instrument name prefix:
-        </para>
+      <para>
+        If you use a pattern, it should be chosen so that it matches all
+        the items of interest and no others. For example, to select all
+        file I/O instruments, it is better to use a pattern that
+        includes the entire instrument name prefix:
+      </para>
 
 <programlisting>
 ... WHERE NAME LIKE 'wait/io/file/%';
 </programlisting>
 
-        <para>
-          A pattern of <literal>'%/file/%'</literal> will match other
-          instruments that have a component of
-          <literal>'/file/'</literal> anywhere in the name. Even less
-          suitable is the pattern <literal>'%file%'</literal> because it
-          will match instruments with <literal>'file'</literal> anywhere
-          in the name, such as
-          <literal>wait/synch/mutex/sql/LOCK_des_key_file</literal>.
-        </para>
+      <para>
+        A pattern of <literal>'%/file/%'</literal> will match other
+        instruments that have a component of <literal>'/file/'</literal>
+        anywhere in the name. Even less suitable is the pattern
+        <literal>'%file%'</literal> because it will match instruments
+        with <literal>'file'</literal> anywhere in the name, such as
+        <literal>wait/synch/mutex/sql/LOCK_des_key_file</literal>.
+      </para>
 
-        <para>
-          To check which instrument or consumer names a pattern matches,
-          perform a simple test:
-        </para>
+      <para>
+        To check which instrument or consumer names a pattern matches,
+        perform a simple test:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT NAME FROM setup_instruments WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>

@@ -1552,8 +1548,6 @@
 mysql&gt; <userinput>SELECT NAME FROM setup_consumers WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 </programlisting>
 
-      </section>
-
     </section>
 
     <section id="performance-schema-consumer-configuration">


Modified: trunk/refman-6.0/performance-schema-core.xml
===================================================================
--- trunk/refman-6.0/performance-schema-core.xml	2011-03-15 17:07:30 UTC (rev 25400)
+++ trunk/refman-6.0/performance-schema-core.xml	2011-03-15 17:07:38 UTC (rev 25401)
Changed blocks: 9, Lines Added: 245, Lines Deleted: 250; 23456 bytes

@@ -1147,39 +1147,41 @@
 
     </section>
 
-    <section id="performance-schema-filtering">
+  </section>
 
-      <title>Event Collection Filtering</title>
+  <section id="performance-schema-filtering">
 
-      <indexterm>
-        <primary>Performance Schema</primary>
-        <secondary>event filtering</secondary>
-      </indexterm>
+    <title>Event Collection Filtering</title>
 
-      <indexterm>
-        <primary>pre-filtering</primary>
-        <secondary>Performance Schema</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>Performance Schema</primary>
+      <secondary>event filtering</secondary>
+    </indexterm>
 
-      <indexterm>
-        <primary>post-filtering</primary>
-        <secondary>Performance Schema</secondary>
-      </indexterm>
+    <indexterm>
+      <primary>pre-filtering</primary>
+      <secondary>Performance Schema</secondary>
+    </indexterm>
 
-      <para>
-        Events are processed in a producer/consumer fashion:
-      </para>
+    <indexterm>
+      <primary>post-filtering</primary>
+      <secondary>Performance Schema</secondary>
+    </indexterm>
 
-      <itemizedlist>
+    <para>
+      Events are processed in a producer/consumer fashion:
+    </para>
 
-        <listitem>
-          <para>
-            Instrumented code is the source for events and produces
-            events to be collected. The
-            <literal role="ps">setup_instruments</literal> table lists
-            the instruments for which events can be collected:
-          </para>
+    <itemizedlist>
 
+      <listitem>
+        <para>
+          Instrumented code is the source for events and produces events
+          to be collected. The
+          <literal role="ps">setup_instruments</literal> table lists the
+          instruments for which events can be collected:
+        </para>
+
 <programlisting>
 mysql&gt; <userinput>SELECT * FROM setup_instruments;</userinput>
 +------------------------------------------------------------+---------+-------+

@@ -1202,15 +1204,15 @@
 | wait/io/file/sql/dbopt                                     | YES     | YES   |
 ...
 </programlisting>
-        </listitem>
+      </listitem>
 
-        <listitem>
-          <para>
-            Performance Schema tables are the destinations for events
-            and consume events. The
-            <literal role="ps">setup_consumers</literal> table lists the
-            destination tables in which event information can be stored:
-          </para>
+      <listitem>
+        <para>
+          Performance Schema tables are the destinations for events and
+          consume events. The
+          <literal role="ps">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>

@@ -1227,50 +1229,18 @@
 | file_summary_by_instance                     | YES     |
 +----------------------------------------------+---------+
 </programlisting>
-        </listitem>
+      </listitem>
 
-      </itemizedlist>
+    </itemizedlist>
 
-      <para>
-        Filtering can be done at different stages of performance
-        monitoring:
-      </para>
+    <para>
+      Filtering can be done at different stages of performance
+      monitoring:
+    </para>
 
-      <itemizedlist>
+    <itemizedlist>
 
-        <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.
-          </para>
-        </listitem>
-
-        <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.
-          </para>
-        </listitem>
-
-      </itemizedlist>
-
-      <para>
-        The following sections provide more detail about each type of
-        filtering.
-      </para>
-
-      <section id="performance-schema-pre-filtering">
-
-        <title>Event Pre-Filtering</title>
-
+      <listitem>
         <para>
           Pre-filtering is done by modifying Performance Schema
           configuration so that only certain types of events are

@@ -1279,130 +1249,161 @@
           by Performance Schema and has a global effect that applies to
           all users.
         </para>
+      </listitem>
 
+      <listitem>
         <para>
-          Pre-filtering can be applied to either the producer or
-          consumer stage of event processing by modifying the
-          <literal role="ps">setup_instruments</literal> or
-          <literal role="ps">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 to collect timing information by setting its
-          <literal>TIMED</literal> value to <literal>YES</literal> or
-          <literal>NO</literal>.
+          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.
         </para>
+      </listitem>
 
-        <para>
-          Reasons to use pre-filtering include the following:
-        </para>
+    </itemizedlist>
 
-        <itemizedlist>
+    <para>
+      The following sections provide more detail about each type of
+      filtering.
+    </para>
 
-          <listitem>
-            <para>
-              Pre-filtering reduces overhead. The overhead should be
-              minimal even with all instruments enabled, but perhaps you
-              want to reduce it further. Or you do not care about timing
-              events and want to disable the timing code to eliminate
-              timing overhead.
-            </para>
-          </listitem>
+    <section id="performance-schema-pre-filtering">
 
-          <listitem>
-            <para>
-              You do not want to fill up the current-events or history
-              tables with events in which you have no interest.
-              Pre-filtering leaves more <quote>room</quote> in these
-              tables for instances of rows for enabled instrument types.
-              If you enable only file instruments with pre-filtering, no
-              rows are collected for nonfile instruments. With
-              post-filtering, nonfile events are collected, leaving
-              fewer rows for file events.
-            </para>
-          </listitem>
+      <title>Event Pre-Filtering</title>
 
-          <listitem>
-            <para>
-              You do not care about maintaining some kinds of event
-              tables. If you disable a consumer, the server does not
-              spend time maintaining it. For example, if you do not care
-              about aggregated event information, you can disable the
-              summary table consumers to improve performance.
-            </para>
-          </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.
+      </para>
 
-        </itemizedlist>
+      <para>
+        Pre-filtering can be applied to either the producer or consumer
+        stage of event processing by modifying the
+        <literal role="ps">setup_instruments</literal> or
+        <literal role="ps">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
+        to collect timing information by setting its
+        <literal>TIMED</literal> value to <literal>YES</literal> or
+        <literal>NO</literal>.
+      </para>
 
-        <para>
-          Example pre-filtering operations:
-        </para>
+      <para>
+        Reasons to use pre-filtering include the following:
+      </para>
 
-        <para>
-          Disable all instruments:
-        </para>
+      <itemizedlist>
 
+        <listitem>
+          <para>
+            Pre-filtering reduces overhead. The overhead should be
+            minimal even with all instruments enabled, but perhaps you
+            want to reduce it further. Or you do not care about timing
+            events and want to disable the timing code to eliminate
+            timing overhead.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            You do not want to fill up the current-events or history
+            tables with events in which you have no interest.
+            Pre-filtering leaves more <quote>room</quote> in these
+            tables for instances of rows for enabled instrument types.
+            If you enable only file instruments with pre-filtering, no
+            rows are collected for nonfile instruments. With
+            post-filtering, nonfile events are collected, leaving fewer
+            rows for file events.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
+            You do not care about maintaining some kinds of event
+            tables. If you disable a consumer, the server does not spend
+            time maintaining it. For example, if you do not care about
+            aggregated event information, you can disable the summary
+            table consumers to improve performance.
+          </para>
+        </listitem>
+
+      </itemizedlist>
+
+      <para>
+        Example pre-filtering operations:
+      </para>
+
+      <para>
+        Disable all instruments:
+      </para>
+
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO';</userinput>
 </programlisting>
 
-        <para>
-          Now no events will be collected. This change, like other
-          pre-filtering operations, affects other users as well, even if
-          they want to see event information.
-        </para>
+      <para>
+        Now no events will be collected. This change, like other
+        pre-filtering operations, affects other users as well, even if
+        they want to see event information.
+      </para>
 
-        <para>
-          Disable all file instruments, adding them to the current set
-          of disabled instruments:
-        </para>
+      <para>
+        Disable all file instruments, adding them to the current set of
+        disabled instruments:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME LIKE 'wait/io/file/%';</userinput>
 </programlisting>
 
-        <para>
-          Disable only file instruments, enable all other instruments:
-        </para>
+      <para>
+        Disable only file instruments, enable all other instruments:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');</userinput>
 </programlisting>
 
-        <para>
-          The preceding queries use the
-          <literal role="op">LIKE</literal> operator and the pattern
-          <literal>'wait/io/file/%'</literal> to match all instrument
-          names that begin with <literal>'wait/io/file/</literal>.
-          Additional information about specifying patterns to select
-          instruments is given later in this section.
-        </para>
+      <para>
+        The preceding queries use the <literal role="op">LIKE</literal>
+        operator and the pattern <literal>'wait/io/file/%'</literal> to
+        match all instrument names that begin with
+        <literal>'wait/io/file/</literal>. Additional information about
+        specifying patterns to select instruments is given later in this
+        section.
+      </para>
 
-        <para>
-          Enable all but those instruments in the
-          <literal>mysys</literal> library:
-        </para>
+      <para>
+        Enable all but those instruments in the <literal>mysys</literal>
+        library:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>
     -&gt; <userinput>SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;</userinput>
 </programlisting>
 
-        <para>
-          Disable a specific instrument:
-        </para>
+      <para>
+        Disable a specific instrument:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET ENABLED = 'NO'</userinput>
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 
-        <para>
-          To toggle the state of an instrument, <quote>flip</quote> its
-          <literal>ENABLED</literal> value:
-        </para>
+      <para>
+        To toggle the state of an instrument, <quote>flip</quote> its
+        <literal>ENABLED</literal> value:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1410,93 +1411,89 @@
     -&gt; <userinput>WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';</userinput>
 </programlisting>
 
-        <para>
-          Changing which instruments are enabled does not flush the
-          history tables. Events already collected remain in the
-          current-events, history, and summary 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. You might want to truncate the summary tables
-          as well to discard aggregate information for previously
-          collected events.
-        </para>
+      <para>
+        Changing which instruments are enabled does not flush the
+        history tables. Events already collected remain in the
+        current-events, history, and summary 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. You might want to
+        truncate the summary tables as well to discard aggregate
+        information for previously collected events.
+      </para>
 
-        <para>
-          Disable timing for all events:
-        </para>
+      <para>
+        Disable timing for all events:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments SET TIMED = 'NO';</userinput>
 </programlisting>
 
-        <para>
-          Setting the <literal>TIMED</literal> column for instruments to
-          <literal>NO</literal> affects Performance Schema table
-          contents as described in
-          <xref linkend="performance-schema-timing"/>.
-        </para>
+      <para>
+        Setting the <literal>TIMED</literal> column for instruments to
+        <literal>NO</literal> affects Performance Schema table contents
+        as described in <xref linkend="performance-schema-timing"/>.
+      </para>
 
-        <para>
-          If you disable a consumer, the server does not spend time
-          maintaining it. For example, you can disable the summary table
-          consumers if you do not care about aggregated event
-          information:
-        </para>
+      <para>
+        If you disable a consumer, the server does not spend time
+        maintaining it. For example, you can disable the summary table
+        consumers if you do not care about aggregated event information:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_consumers</userinput>
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 
-      </section>
+    </section>
 
-      <section id="performance-schema-post-filtering">
+    <section id="performance-schema-post-filtering">
 
-        <title>Event Post-Filtering</title>
+      <title>Event Post-Filtering</title>
 
-        <para>
-          Pre-filtering limits which event information is collected and
-          is independent of any particular user. By contrast,
-          post-filtering is performed by individual users and is
-          performed by use of appropriate <literal>WHERE</literal>
-          clauses that restrict what event information to select from
-          the information available after pre-filtering has been
-          applied.
-        </para>
+      <para>
+        Pre-filtering limits which event information is collected and is
+        independent of any particular user. By contrast, post-filtering
+        is performed by individual users and is performed by use of
+        appropriate <literal>WHERE</literal> clauses that restrict what
+        event information to select from the information available after
+        pre-filtering has been applied.
+      </para>
 
-        <para>
-          Reasons to use post-filtering include the following:
-        </para>
+      <para>
+        Reasons to use post-filtering include the following:
+      </para>
 
-        <itemizedlist>
+      <itemizedlist>
 
-          <listitem>
-            <para>
-              To avoid making decisions for individual users about which
-              event information is of interest.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            To avoid making decisions for individual users about which
+            event information is of interest.
+          </para>
+        </listitem>
 
-          <listitem>
-            <para>
-              To use Performance Schema to investigate a performance
-              issue when the restrictions to impose using pre-filtering
-              are not known in advance.
-            </para>
-          </listitem>
+        <listitem>
+          <para>
+            To use Performance Schema to investigate a performance issue
+            when the restrictions to impose using pre-filtering are not
+            known in advance.
+          </para>
+        </listitem>
 
-        </itemizedlist>
+      </itemizedlist>
 
-        <para>
-          In <xref linkend="performance-schema-pre-filtering"/>, an
-          example showed how to pre-filter for file instruments. If the
-          event tables contain both file and nonfile information,
-          post-filtering is another way to see information only for file
-          events. Add a <literal>WHERE</literal> clause to queries to
-          restrict event selection appropriately:
-        </para>
+      <para>
+        In <xref linkend="performance-schema-pre-filtering"/>, an
+        example showed how to pre-filter for file instruments. If the
+        event tables contain both file and nonfile information,
+        post-filtering is another way to see information only for file
+        events. Add a <literal>WHERE</literal> clause to queries to
+        restrict event selection appropriately:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT THREAD_ID, NUMBER_OF_BYTES</userinput>

@@ -1514,11 +1511,11 @@
 +-----------+-----------------+
 </programlisting>
 
-        <para>
-          Names given for filtering operations can be as specific or
-          general as required. To indicate a single instrument or
-          consumer, specify its name in full:
-        </para>
+      <para>
+        Names given for filtering operations can be as specific or
+        general as required. To indicate a single instrument or
+        consumer, specify its name in full:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1529,10 +1526,10 @@
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME = 'file_summary_by_instance';</userinput>
 </programlisting>
 
-        <para>
-          To specify a group of instruments or consumers, use a pattern
-          that matches the group members:
-        </para>
+      <para>
+        To specify a group of instruments or consumers, use a pattern
+        that matches the group members:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>UPDATE setup_instruments</userinput>

@@ -1543,31 +1540,31 @@
     -&gt; <userinput>SET ENABLED = 'NO' WHERE NAME LIKE '%summary%';</userinput>
 </programlisting>
 
-        <para>
-          If you use a pattern, it should be chosen so that it matches
-          all the items of interest and no others. For example, to
-          select all file I/O instruments, it is better to use a pattern
-          that includes the entire instrument name prefix:
-        </para>
+      <para>
+        If you use a pattern, it should be chosen so that it matches all
+        the items of interest and no others. For example, to select all
+        file I/O instruments, it is better to use a pattern that
+        includes the entire instrument name prefix:
+      </para>
 
 <programlisting>
 ... WHERE NAME LIKE 'wait/io/file/%';
 </programlisting>
 
-        <para>
-          If you use a pattern of <literal>'%/file/%'</literal>, it will
-          match other instruments that have a component of
-          <literal>'/file/'</literal> anywhere in the name. Even less
-          suitable is the pattern <literal>'%file%'</literal> because it
-          will match instruments with <literal>'file'</literal> anywhere
-          in the name, such as
-          <literal>wait/synch/mutex/sql/LOCK_des_key_file</literal>.
-        </para>
+      <para>
+        If you use a pattern of <literal>'%/file/%'</literal>, it will
+        match other instruments that have a component of
+        <literal>'/file/'</literal> anywhere in the name. Even less
+        suitable is the pattern <literal>'%file%'</literal> because it
+        will match instruments with <literal>'file'</literal> anywhere
+        in the name, such as
+        <literal>wait/synch/mutex/sql/LOCK_des_key_file</literal>.
+      </para>
 
-        <para>
-          To check which instrument or consumer names a pattern matches,
-          perform a simple test:
-        </para>
+      <para>
+        To check which instrument or consumer names a pattern matches,
+        perform a simple test:
+      </para>
 
 <programlisting>
 mysql&gt; <userinput>SELECT NAME FROM setup_instruments WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>

@@ -1575,8 +1572,6 @@
 mysql&gt; <userinput>SELECT NAME FROM setup_consumers WHERE NAME LIKE '<replaceable>pattern</replaceable>';</userinput>
 </programlisting>
 
-      </section>
-
     </section>
 
   </section>


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