# N+1 problem in the list of generic relations

**URL:** <https://forum.djangoproject.com/t/n-1-problem-in-the-list-of-generic-relations/37484>\
**Category:** Using the ORM\
**Created:** [December 25, 2024, 5:38pm UTC](https://forum.djangoproject.com/t/n-1-problem-in-the-list-of-generic-relations/37484 "2024-12-25T17:38:32Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [December 25, 2024, 6:11pm UTC](https://forum.djangoproject.com/t/n-1-problem-in-the-list-of-generic-relations/37484/2 "2024-12-25T18:11:04Z")

</div>

> [@leksuss](#):
>
> And how to resolve this issue in common way?

If the issue is a real performance issue based upon measurements of real problems and not just the identification of an N+1 situation, then the solution is to restructure your data to avoid using GFKs. (And given that the Admin should _not_ be your primary interface from a user-facing perspective, the N+1 issue in the Admin really shouldn’t be a huge problem.)

See [Avoid Django's GenericForeignKey - lukeplant.me.uk](https://lukeplant.me.uk/blog/posts/avoid-django-genericforeignkey/) and [Generic relation vs Many to Many](https://forum.djangoproject.com/t/generic-relation-vs-many-to-many/16967/) for a couple of perspectives on this. (The first article in particular identifies some alternatives.)

---

_[View the full topic](https://forum.djangoproject.com/t/n-1-problem-in-the-list-of-generic-relations/37484)._