discourse/db/migrate/20240306063428_add_indexes_to_notifications.rb

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

40 lines
923 B
Ruby
Raw Normal View History

PERF: Add indexes to speed up notifications queries by user menu (#26048) Why this change? There are two problematic queries in question here when loading notifications in various tabs in the user menu: ``` SELECT "notifications".* FROM "notifications" LEFT JOIN topics ON notifications.topic_id = topics.id WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL) ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC, notifications.created_at DESC LIMIT 30; ``` and ``` EXPLAIN ANALYZE SELECT "notifications".* FROM "notifications" LEFT JOIN topics ON notifications.topic_id = topics.id WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL) AND "notifications"."notification_type" IN (5, 19, 25) ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30; ``` For a particular user, the queries takes about 40ms and 26ms respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total. What does this change do? 1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read) DESC, created_at DESC)`. 1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications` table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause. With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
2024-03-06 16:52:19 +08:00
# frozen_string_literal: true
class AddIndexesToNotifications < ActiveRecord::Migration[7.0]
disable_ddl_transaction!
def up
execute <<~SQL
DROP INDEX IF EXISTS index_notifications_user_menu_ordering
SQL
execute <<~SQL
CREATE INDEX CONCURRENTLY index_notifications_user_menu_ordering
ON notifications (
user_id,
(high_priority AND NOT read) DESC,
(NOT read) DESC,
created_at DESC
);
SQL
execute <<~SQL
DROP INDEX IF EXISTS index_notifications_user_menu_ordering_deprioritized_likes
SQL
execute <<~SQL
CREATE INDEX CONCURRENTLY index_notifications_user_menu_ordering_deprioritized_likes
ON notifications (
user_id,
(high_priority AND NOT read) DESC,
(NOT read AND notification_type NOT IN (5,19,25)) DESC,
created_at DESC
);
SQL
end
def down
raise ActiveRecord::IrreversibleMigration
end
end