Fix slow events query for followed users
What does this MR do and why?
The MR fixes the slow IN query used to fetch events for followed users in Activities page using the IN operator optimization only when the event filter used is ALL (i.e., no filtering condition in the query).
Improving the IN queries with event filters requires a larger work and should be tracked separately.
Query plan comparisons
query without offset (w/ 9 followers)
- Query plan (before): https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/7687/commands/27306
- Query plan (after): https://explain-depesz.postgres.ai/s/bR
query with offset (w/ 9 followers)
- Query plan (after): https://explain-depesz.postgres.ai/s/cQ
Migration output
Up
== 20211217145923 AddIndexToEventsOnAuthorIdAndActionAndId: migrating =========
-- transaction_open?()
-> 0.0000s
-- index_exists?(:events, [:author_id, :action, :id], {:name=>"index_events_on_author_id_and_action_and_id", :algorithm=>:concurrently})
-> 0.0056s
-- execute("SET statement_timeout TO 0")
-> 0.0004s
-- add_index(:events, [:author_id, :action, :id], {:name=>"index_events_on_author_id_and_action_and_id", :algorithm=>:concurrently})
-> 0.0090s
-- execute("RESET statement_timeout")
-> 0.0012s
== 20211217145923 AddIndexToEventsOnAuthorIdAndActionAndId: migrated (0.0188s)
Down
== 20211217145923 AddIndexToEventsOnAuthorIdAndActionAndId: reverting =========
-- transaction_open?()
-> 0.0000s
-- indexes(:events)
-> 0.0101s
-- execute("SET statement_timeout TO 0")
-> 0.0005s
-- remove_index(:events, {:algorithm=>:concurrently, :name=>"index_events_on_author_id_and_action_and_id"})
-> 0.0073s
-- execute("RESET statement_timeout")
-> 0.0006s
== 20211217145923 AddIndexToEventsOnAuthorIdAndActionAndId: reverted (0.0280s)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by euko