Opened 4 years ago

Last modified 4 years ago

#17659 new Cleanup/optimization

django_admin_log searches are slow

Reported by: anonymous Owned by: keeff
Component: contrib.admin Version: 1.3
Severity: Normal Keywords:
Cc: anssi.kaariainen@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


Queries against django_admin_log are slow because the soft-reference columns are not indexed.

Attachments (1)

django-logentry-index.diff (900 bytes) - added by keeff+django@… 4 years ago.
Patch to add indexes to django_admin_log

Download all attachments as: .zip

Change History (5)

Changed 4 years ago by keeff+django@…

Patch to add indexes to django_admin_log

comment:1 Changed 4 years ago by keeff

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to keeff
  • Patch needs improvement unset

comment:2 Changed 4 years ago by akaariai

  • Cc anssi.kaariainen@… added

Adding some indexes makes sense to me. However, it would be nice to confirm both indexes are actually needed.

Is it possible to provide some data on how these indexes are used in the queries Django generates for realworld data? EXPLAIN ANALYZE from PostgreSQL would be perfect.

Multicolumn index could be the best solution here, but unfortunately that isn't currently supported. If possible, data for multicolumn index too would be great.

comment:3 Changed 4 years ago by anonymous

object_id is used in stock django, i.e. history_view() in contrib/admin/ The index here is a clear win for any who use django_admin_log.

object_repr is often used in custom forms and other external code, one common example is to implement a global history search. Doing this via object_id is not reasonable since this would involve working out the object_id for all matching objects in every extant model, and even then it may not be viable to match history for deleted objects. Such forms should be efficient without needing a local modification to contrib/admin/

comment:4 Changed 4 years ago by akaariai

  • Has patch set
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

I wonder if it is really necessary to have the index for object_repr alone though. Every django installation using admin would need to pay the price of that index, but it is not needed in stock installations. I have written multiple django apps, and never needed object_repr lookups. You can add the index by hand if needed.

So, I would say +1 on the object_id index, and more proof for the need of object_repr index.

Marking as accepted on the basis of need for object_id index. Although query plans with the index and without it are still missing.

Note: See TracTickets for help on using tickets.
Back to Top