Alvar Penning 2b7c21ade2 schema: Index user_notification_history.notification_history_id ... 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.		2026-01-13 09:26:41 +01:00
..
optional	Bump version to 1.2.0	2024-04-11 13:23:34 +02:00
1.0.0-rc2.sql	schema/mysql: Use UNIX_TIMESTAMP() instead of CURRENT_TIMESTMAP()	2024-03-18 10:22:35 +01:00
1.0.0.sql	schema/mysql: Use UNIX_TIMESTAMP() instead of CURRENT_TIMESTMAP()	2024-03-18 10:22:35 +01:00
1.1.1.sql	schema/mysql: Use UNIX_TIMESTAMP() instead of CURRENT_TIMESTMAP()	2024-03-18 10:22:35 +01:00
1.2.0.sql	Bump version to 1.2.0	2024-04-11 13:23:34 +02:00
1.2.1.sql	Release Icinga DB Version 1.2.1	2024-12-18 10:45:22 +01:00
1.4.0.sql	Make is_acknowledged a boolenum & add is_sticky_acknowledgement	2025-06-05 14:23:23 +02:00
1.5.2-pr1059.sql	schema: Index user_notification_history.notification_history_id	2026-01-13 09:26:41 +01:00