mirror of
https://github.com/Icinga/icingadb.git
synced 2026-02-18 18:18:00 -05:00
2b7c21ade2
Add a new INDEX to user_notification_history.notification_history_id to speed up the notification history retention. This column is a FOREIGN KEY to notification_history with a "ON DELETE CASCADE" clause. The notification_history table can be cleaned up by the notification retention, resulting in lots of DELETE queries. However, without the INDEX, the DELETE CASCADE might result in a full table scan for each retention operation. I have further checked every other retention table, but no other had the same issue. Most retention tables have their primary key referenced by a foreign key in the history table, where indexes were already present. Many thanks to @rezemble for both reporting this issue and coming up with the exact solution. Fixes #1003.
2 lines
226 B
SQL
2 lines
226 B
SQL
CREATE INDEX idx_user_notification_history_notification_history_id ON user_notification_history(notification_history_id);
|
|
COMMENT ON INDEX idx_user_notification_history_notification_history_id IS 'Speed up ON DELETE CASCADE';
|