#30867: Old indexes should be dropped after new ones are created.
-------------------------------------+-------------------------------------
Reporter: Simon Charette | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
> Why do you see that as a problem? Shouldn't the time between the two
commands be rather short?
Unique constraint creation can be relatively slow on large tables
particularly when performed without a lock (e.g. MySQL `LOCK=NONE`) to
allow concurrent read and writes. During that time period not having an
index on a frequently queried column can cause such queries to take a a
few orders more time to process and thus slowdown the constraint creation
time even more. At least that's what we've experienced on a table with 6M
rows when adding a unique constraint on a `VARCHAR(255) NOT NULL`.
> I think that reduced performance is something we could expect during the
execution of a migration.
Agreed but if we can reduce the performance degradation at the cost of
temporarily elevated storage needs I think we should do it.
Is there any reason except for double index storage needs not to do it?
--
Ticket URL: <https://code.djangoproject.com/ticket/30867#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.d05e311bb3fdc01989bdb67029ec43c6%40djangoproject.com.
