WL#7795: PERFORMANCE SCHEMA, HISTORY PER THREAD

Currently, consumer flags control whether or not to log history events, for the
respective events (waits, stages, statements and transactions).

These flags are global to the server, so that collection of historical data for
different threads is either all or nothing.

With this feature, the DBA can specify for which sessions / accounts / users /
hosts to collect historical data, separatly from turning instrumentation on or
off for the same sessions / accounts / users / hosts.

This allows to control more precisely what events are logged in history tables,
which:
- decrease the runtime overhead, when historical data is needed only for a
subset of the instrumented sessions
- reduce the noise in events_waits_history_long, events_stages_history_long,
events_statements_history_long, events_transactions_history_long tables, which
facilitates troubleshooting on busy servers (that generates a lot of events)

User Documentation
==================

http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-8.html
http://dev.mysql.com/doc/refman/5.7/en/performance-schema-pre-
filtering.html#performance-schema-thread-filtering
http://dev.mysql.com/doc/refman/5.7/en/setup-actors-table.html
http://dev.mysql.com/doc/refman/5.7/en/threads-table.html

Requirements
============

(1) Table performance_schema.setup_actors.
-------------------------------------------

Func-Req (1.1): A fresh MySQL installation of CURRENT-VERSION must create the
table performance_schema.setup_actors with the new HISTORY column.

Func-Req (1.2): An upgrade from PREVIOUS-VERSION to CURRENT-VERSION must create
the table performance_schema.setup_actors with the new HISTORY column.

Func-Req (1.3): Security privileges for column setup_actors.HISTORY
are enforced. This column can be updated, by users with the proper grants.

Func-Req (1.4): Table performance_schema.setup_actors contains, by default, the
following values:
- HOST="%", USER="%", ROLE="%", ENABLED="YES", HISTORY="YES"

(2) Table performance_schema.threads.
-------------------------------------

Func-Req (2.1): A fresh MySQL installation of CURRENT-VERSION must create the
table performance_schema.threads with the new HISTORY column.

Func-Req (2.2): An upgrade from PREVIOUS-VERSION to CURRENT-VERSION must create
the table performance_schema.threads with the new HISTORY column.

Func-Req (2.3): Security privileges for column threads.HISTORY
are enforced. This column can be updated, by users with the proper grants.

(3) History tables.
-------------------

Data is collected in the respective tables only if the HISTORY column for the
running thread, in table performance_schema.thread, is 'YES'
- Func-Req (3.1) events_waits_history
- Func-Req (3.2) events_waits_history_long
- Func-Req (3.3) events_stages_history
- Func-Req (3.4) events_stages_history_long
- Func-Req (3.5) events_statements_history
- Func-Req (3.6) events_statements_history_long
- Func-Req (3.7) events_transactions_history
- Func-Req (3.8) events_transactions_history_long

TABLE performance_schema.SETUP_ACTORS
======================================

Add the following column after the ENABLED column:

  `HISTORY` enum('YES','NO') NOT NULL

Operations
----------

The HISTORY column can be updated.

A user must have the proper privileges to perform these operations.

NOTE: Update on HISTORY column doesn't affect the existing foreground threads
from same user/host.

Semantic
========

See the existing documentation for 5.7:
http://dev.mysql.com/doc/refman/5.7/en/setup-actors-table.html

When the Performance Schema checks for a match in setup_actors, it finds the
proper row according to existing rules, to decide whether the new session is
instrumented or not (column threads.INSTRUMENTED set to setup_actors.ENABLED).

The column threads.HISTORY is initialized with setup_actors.HISTORY for new
sessions.

TABLE performance_schema.threads
================================

Add the following column after the INSTRUMENTED column:

  `HISTORY` enum('YES','NO') NOT NULL

Operations
----------

The HISTORY column can be updated.

A user must have the proper privileges to perform these operations.

Semantic
========

When HISTORY = 'NO', nothing for this thread is recorded in the following tables:
- events_waits_history
- events_waits_history_long
- events_stages_history
- events_stages_history_long
- events_statements_history
- events_statements_history_long
- events_transactions_history
- events_transactions_history_long

When HISTORY = 'YES', events for this thread are recorded in the history tables
according to existing rules (consumers in table setup_consumers controls which
table is populated)