<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="performance-schema-pre-filtering">
      </a>
      29.4.3 Event Pre-Filtering
     </h3>
    </div>
   </div>
  </div>
  <p>
   Pre-filtering is done by the Performance Schema and has a global
        effect that applies to all users. Pre-filtering can be applied
        to either the producer or consumer stage of event processing:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      To configure pre-filtering at the producer stage, several
            tables can be used:
     </p>
     <div class="itemizedlist">
      <ul class="itemizedlist" style="list-style-type: circle; ">
       <li class="listitem">
        <p>
         <a class="link" href="performance-schema-setup-instruments-table.html" title="29.12.2.3 The setup_instruments Table">
          <code class="literal">
           setup_instruments
          </code>
         </a>
         indicates
                which instruments are available. An instrument disabled
                in this table produces no events regardless of the
                contents of the other production-related setup tables.
                An instrument enabled in this table is permitted to
                produce events, subject to the contents of the other
                tables.
        </p>
       </li>
       <li class="listitem">
        <p>
         <a class="link" href="performance-schema-setup-objects-table.html" title="29.12.2.4 The setup_objects Table">
          <code class="literal">
           setup_objects
          </code>
         </a>
         controls
                whether the Performance Schema monitors particular table
                and stored program objects.
        </p>
       </li>
       <li class="listitem">
        <p>
         <a class="link" href="performance-schema-threads-table.html" title="29.12.22.8 The threads Table">
          <code class="literal">
           threads
          </code>
         </a>
         indicates whether
                monitoring is enabled for each server thread.
        </p>
       </li>
       <li class="listitem">
        <p>
         <a class="link" href="performance-schema-setup-actors-table.html" title="29.12.2.1 The setup_actors Table">
          <code class="literal">
           setup_actors
          </code>
         </a>
         determines the
                initial monitoring state for new foreground threads.
        </p>
       </li>
      </ul>
     </div>
    </li>
    <li class="listitem">
     <p>
      To configure pre-filtering at the consumer stage, modify the
      <a class="link" href="performance-schema-setup-consumers-table.html" title="29.12.2.2 The setup_consumers Table">
       <code class="literal">
        setup_consumers
       </code>
      </a>
      table. This
            determines the destinations to which events are sent.
      <a class="link" href="performance-schema-setup-consumers-table.html" title="29.12.2.2 The setup_consumers Table">
       <code class="literal">
        setup_consumers
       </code>
      </a>
      also implicitly
            affects event production. If a given event is not sent to
            any destination (that is, it is never consumed), the
            Performance Schema does not produce it.
     </p>
    </li>
   </ul>
  </div>
  <p>
   Modifications to any of these tables affect monitoring
        immediately, with the exception that modifications to the
   <a class="link" href="performance-schema-setup-actors-table.html" title="29.12.2.1 The setup_actors Table">
    <code class="literal">
     setup_actors
    </code>
   </a>
   table affect only
        foreground threads created subsequent to the modification, not
        existing threads.
  </p>
  <p>
   When you change the monitoring configuration, the 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
   <a class="link" href="truncate-table.html" title="15.1.37 TRUNCATE TABLE Statement">
    <code class="literal">
     TRUNCATE TABLE
    </code>
   </a>
   to empty the
        history tables.
  </p>
  <p>
   After making instrumentation changes, you might want to truncate
        the summary tables. Generally, the effect is to reset the
        summary columns to 0 or
   <code class="literal">
    NULL
   </code>
   , not to remove
        rows. This enables you to clear collected values and restart
        aggregation. That might be useful, for example, after you have
        made a runtime configuration change. Exceptions to this
        truncation behavior are noted in individual summary table
        sections.
  </p>
  <p>
   The following sections describe how to use specific tables to
        control Performance Schema pre-filtering.
  </p>
 </div>
 <br/>
</div>
