Description:

As a database administrator, I want sampled session data to be stored efficiently and manageably so that I can retain historical data without overwhelming system resources.

Acceptance Criteria:

1. Store data in a new table within the performance_schema, e.g., session_history, accessible via SQL, with columns as specified in the metrics table.
2. Allow configuration of the maximum number of rows to retain via a system variable (e.g., performance_schema_session_history_size, default: 1,000,000 rows), overriding the original ash_max_size_mb for simplicity in memory management.
3. Implement a ring buffer mechanism where the oldest rows are automatically discarded when the maximum number of rows is reached.
4. Optimize the table for fast insertion and querying, using appropriate indexing (e.g., on sample_time and session_id).
5. Retention is implicitly tied to the number of rows; with a default of 1,000,000 rows, sampling every 1 second across 100 sessions provides approximately 2.7 hours of history.

Server Enhancement Requirements:

New Table: Add a new table, session_history, to the performance_schema with the columns specified in the metrics table story.
Performance Schema Extension: Extend the performance_schema engine to manage this table, including a mechanism to discard the oldest rows when the configured limit (performance_schema_session_history_size) is reached.
Storage Optimization: Design the table to be memory-based (consistent with performance_schema) and optimized for high insertion rates. Data is lost on server restart, which is acceptable for ASH-like recent history monitoring.
Configuration Variable: Introduce performance_schema_session_history_size as a system variable to control the maximum number of rows, allowing administrators to balance memory usage and retention duration.