[Django] #32838: Migrations create extra index when foreign key is also part of a unique constraint

3 views

Skip to first unread message

Django

unread,

Jun 11, 2021, 2:33:49 AM6/11/21

to django-...@googlegroups.com

#32838: Migrations create extra index when foreign key is also part of a unique
constraint
-------------------------------------+-------------------------------------
Reporter: levkk | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database | Version: 3.2
layer (models, ORM) | Keywords:
Severity: Normal | postgres,indexes,unique
Triage Stage: | constraint,foreign keys
Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Given a model like so:

{{{
class Person(models.Model):
name = models.TextField()

class Address(models.Model):
person = models.ForeignKey(Person, on_delete=models.PROTECT)
street = models.TextField()

class Meta:
unique_together = ["person", "street"]
}}}

and a Postgres backend, Django will create two btree indexes, one on the
foreign key "person" and another on "person, street" to enforce the unique
constraint. In this case, the "person" index is redundant and wasteful
since the "person, street" index is sufficient. We can check for the
foreign key index being covered by the unique index and not create it if
that's the case.

--
Ticket URL: <https://code.djangoproject.com/ticket/32838>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

Jun 11, 2021, 4:29:37 AM6/11/21

to django-...@googlegroups.com

#32838: Migrations create extra index when foreign key is also part of a unique
constraint
-------------------------------------+-------------------------------------

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Mariusz Felisiak):

* status: new => closed
* resolution: => wontfix

Comment:

Thanks for this ticket, however it is a
[https://docs.djangoproject.com/en/3.2/ref/models/fields/#foreignkey
documented] behavior. It's also documented how to disable `ForeignKey`
indexes if you want to avoid the overhead:

''A database index is automatically created on the `ForeignKey`. You can
disable this by setting `db_index` to `False`. You may want to avoid the
overhead of an index if you are creating a foreign key for consistency
rather than joins, or if you will be creating an alternative index like a
partial or **multiple column index**.''

There are also valid cases for a separate index (see
[https://code.djangoproject.com/ticket/22125#comment:17 comment]). IMO we
shouldn't break this.

You can raise the idea on the DevelopersMailingList to reach a wider
audience and see what other think. We can re-open this ticket if we reach
consensus on the mailing list.