Example Consumer Configurations digest without having to collect statistics in  events_statements_current , which is advantageous in terms of overhead. Conversely, you can get detailed statements in  events_statements_current without digests (the  DIGEST  and  DIGEST_TEXT  columns are  NULL  in this case). For more information about statement digesting, see Section 27.10, “Performance Schema Statement Digests and Sampling” . The consumer settings in the  setup_consumers  table form a hierarchy from higher levels to lower. The following discussion describes how consumers work, showing specific configurations and their effects as consumer settings are enabled progressively from high to low. The consumer values shown are representative. The general principles described here apply to other consumer values that may be available. The configuration descriptions occur in order of increasing functionality and overhead. If you do not need the information provided by enabling lower-level settings, disable them so that the Performance Schema executes less code on your behalf and there is less information to sift through. The  setup_consumers  table contains the following hierarchy of values: In the consumer hierarchy, the consumers for waits, stages, statements, and transactions are all at the same level. This differs from the event nesting hierarchy, for which wait events nest within stage events, which nest within statement events, which nest within transaction events. If a given consumer setting is  NO , the Performance Schema disables the instrumentation associated with the consumer and ignores all lower-level settings. If a given setting is  YES , the Performance Schema enables the instrumentation associated with it and checks the settings at the next lowest level. For a description of the rules for each consumer, see Section 27.4.7, “Pre-Filtering by Consumer” . For example, if  global_instrumentation  is enabled,  thread_instrumentation  is checked. If thread_instrumentation  is enabled, the  events_ xxx _current  consumers are checked. If of these events_waits_current  is enabled,  events_waits_history  and  events_waits_history_long are checked. Each of the following configuration descriptions indicates which setup elements the Performance Schema checks and which output tables it maintains (that is, for which tables it collects information). 4918 •No Instrumentation •Global Instrumentation Only Note 27.4.8 Example Consumer Configurations global_instrumentation  thread_instrumentation events_waits_current events_waits_history events_waits_history_long events_stages_current events_stages_history events_stages_history_long events_statements_current events_statements_history events_statements_history_long events_transactions_current events_transactions_history events_transactions_history_long  statements_digest