Now the Performance Schema determines how to set the INSTRUMENTED  and HISTORY  values for new connection threads as follows: 

•If joe  connects from the local host, the connection matches the first inserted row. The INSTRUMENTED and HISTORY  values for the thread become YES . 

•If joe  connects from hosta.example.com , the connection matches the second inserted row. The INSTRUMENTED  value for the thread becomes YES  and the HISTORY  value becomes NO . 

•If joe  connects from any other host, there is no match. The INSTRUMENTED  and HISTORY  values for the thread become NO . 

•If sam  connects from any host, the connection matches the third inserted row. The INSTRUMENTED value for the thread becomes NO  and the HISTORY  value becomes YES . 

•For any other connection, the row with HOST  and USER  set to ’%’  matches. This row now has ENABLED and HISTORY  set to NO , so the INSTRUMENTED  and HISTORY  values for the thread become NO . 

Modifications to the setup_actors  table affect only foreground threads created subsequent to the modification, not existing threads. To affect existing threads, modify the INSTRUMENTED  and HISTORY columns of threads  table rows. 

## 27.4.7 Pre-Filtering by Consumer 

The setup_consumers  table lists the available consumer types and which are enabled: 

mysql> SELECT * FROM performance_schema.setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | YES | | events_transactions_history | YES | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+ 

Modify the setup_consumers  table to affect pre-filtering at the consumer stage and determine the destinations to which events are sent. To enable or disable a consumer, set its ENABLED  value to YES  or NO . 

Modifications to the setup_consumers  table affect monitoring immediately. 

If you disable a consumer, the server does not spend time maintaining destinations for that consumer. For example, if you do not care about historical event information, disable the history consumers: 

UPDATE performance_schema.setup_consumers SET ENABLED = ’NO’ WHERE NAME LIKE ’%history%’; 

The consumer settings in the setup_consumers  table form a hierarchy from higher levels to lower. The following principles apply: 

