Alarm event partitioning and indexing

In the name of controlling overall DB size and having quick query speeds, has IA ever considered auto partitioning of alarm events per month like tag history does?

This would allow for a retention policy to be enacted which does not cause blocking which delete commands cause.

Also, what is the reason to have indexes only on 3 columns of the alarm_events table?

As it grows, queries become increasingly slow until the alarm journal component will time out…that is unless the proper maintenance is done.