Context Navigation

Changes between Initial Version and Version 1 of Ticket #30867, comment 7

initial	v1
1		After a bit of investigation it looks like this would effectively add a lot of complexity to the already complex `_alter_field` for little benefit because the optimization is only valuable when only performing a `(db_index=True)` to `(unique=True)` migration. If the field type is also meant to be altered (e.g type) we certainly want to drop the index before hand to avoid an internal rebuild with the new type which makes it hard to determine when the optimization should be performed.
	1	After a bit of investigation it looks like this would effectively add a lot of complexity to the already complex `_alter_field` for little benefit because the optimization is only valuable when only performing a field alteration that is only `(db_index=True)` to `(unique=True)` migration. If the field type is also meant to be altered (e.g type) we certainly want to drop the index before hand to avoid an internal rebuild with the new type which makes it hard to determine when the optimization should be performed.
2	2
3	3	For the record I managed to get a noticeable speed up (10-15%) on PostgreSQL when adding a unique constraint to an already indexed column (10M rows integer).