Vishnu Narayanan 462ab5241c perf: fix notifications duplicate query and add composite index (#12110) ... Database CPU utilization was spiking due to expensive notification COUNT queries. Analysis revealed two critical issues: 1. Missing database index: Notification count queries were performing table scans without proper indexing 2. Duplicate WHERE clauses: SQL queries contained redundant read_at IS NULL conditions, causing unnecessary query complexity ### Root Cause Analysis The expensive queries were: ``` -- 41.61 calls/sec with duplicate condition SELECT COUNT(*) FROM "notifications" WHERE "notifications"."user_id" = $1 AND "notifications"."account_id" = $2 AND "notifications"."snoozed_until" IS NULL AND "notifications"."read_at" IS NULL AND "notifications"."read_at" IS NULL -- Duplicate! ``` This was caused by a logic error in NotificationFinder#unread_count introduced in commit cd06b2b33 (PR #8907). The method assumed @notifications contained all notifications, but @notifications was already filtered to unread notifications in most cases. ### The Default Query Flow: 1. Frontend calls: NotificationsAPI.getUnreadCount() → /notifications/unread_count 2. No parameters sent, so params = {} 3. NotificationFinder setup: - find_all_notifications: WHERE user_id = ? AND account_id = ? - filter_snoozed_notifications: WHERE snoozed_until IS NULL - filter_read_notifications: WHERE read_at IS NULL (because type_included?('read') is false) 4. unread_count called: Adds another WHERE read_at IS NULL ---- ### Solution 1. Added Missing Database Index - Index: (user_id, account_id, snoozed_until, read_at) 2. Fixed Duplicate WHERE Clause Logic		2025-08-07 15:59:40 +05:30
..
migrate	perf: fix notifications duplicate query and add composite index (#12110)	2025-08-07 15:59:40 +05:30
schema.rb	perf: fix notifications duplicate query and add composite index (#12110)	2025-08-07 15:59:40 +05:30
seeds.rb	chore: Enable the new Rubocop rules (#7122)	2023-05-19 14:37:10 +05:30