Partition the audit_events table by year
Once we start tracking frequent events such as #1411 (closed) - querying the
audit_events table will become slower. Update: #1411 (closed) was released in 12.3 behind a flag due to performance concerns. This issue should enable this logging to become generally available.
- Confirm if partitioning by audit_events is the right action to take
- Partition the
audit_eventstable by range on the
- Tables should be created for each year with a schema like
audit_events-yyyyspecifying the year of the relevant records
This is similar to the work being done to partition the
events table #24538.
This issue is blocked by other database partitioning efforts. Here is the plan: