Partitioning: Identify access patterns for Audit Events

Function	Level	Query	Query example + timing
View project audit_events	Project-level	Count all project-level events	3035ms
	Project-level	View first page	<1ms
	Project-level	View last page (of 560k events)	72,000ms (timeout)
	Project-level	Add created_at filter for 10/2019-31/2019 (count-all)	Cold: HTTP 500 (>60s) Warm: 1663ms (as per pb)
	Project-level	Add created_at filter for 10/2019-31/2019 (view first page)	Warm: 496ms
	Project-level	Pagination with date filter effectively not possible on GitLab.com (random replica, high likelyhood of cold cache => HTTP/500)
View group audit events	Group-level	Similar to project-level in terms of functionality, but entity_type = 'Group'
	Group-level	Feature flag audit_log_group_level - adds events from all projects below this group (not enabled currently)	HTTP/500 consistently even for small group
API: Instance Audit Events	Instance level	Optional filter by created_at, user/group/project
API: Group Audit Events	Group-level	Filter on the group plus additional by created_at
Admin UI		Same filters/access as API

So in summary, we can combine the following filters:

Filter
None	Global admin UI view
Date range	By created_at
Entity type	By group, group including all projects in tree, project, user