#33928: Performance issues with `on_delete=models.SET_NULL` on large tables
-------------------------------------+-------------------------------------
Reporter: Renan GEHAN | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
You are right that is an opportunity for an optimization when `SET`,
`SET_DEFAULT`, or `SET_NULL` is used but I wonder if it's worth doing
given `db_on_delete` support (see #21961) make things even better for this
use case.
> In the meantime, I'll switch to on_delete=models.CASCADE, which in my
case does the trick, but I was curious about the reason why this happens
in the first place.
This is likely the case because the collector is able to take
[https://github.com/django/django/blob/08688bd7dd8dfa218ecff03d6c94a753b1be8e59/django/db/models/deletion.py#L318-L320
the fast delete route] and avoid object fetching entirely.
If you want to give a shot at a patch you'll want to have a look at
`Collector.collect` and have it skip collection entirely when dealing with
`SET` and friends likely by adding a branch that turns them into ''fast''
updates.
[https://github.com/django/django/blob/08688bd7dd8dfa218ecff03d6c94a753b1be8e59/django/db/models/deletion.py#L500-L504
One branch that worries me is the post-deletion assignment of values to
in-memory instances] but I can't understand why this is even necessary
given all the instances that are collected for field updates are never
make their way out of the collector so I would expect it to be entirely
unnecessary.
You'll want to make sure to avoid breaking the
[https://github.com/django/django/blob/0dd29209091280ccf34e07c9468746c396b7778e/django/contrib/admin/utils.py#L164-L228
admin's collector subclass used to display deletion confirmation pages]
but from a quick look it doesn't seem to care about field updates.
Tentatively accepting but I think we should revisit when #21961 lands. In
the mean time if you want to give a shot at implementing this optimization
--
Ticket URL: <https://code.djangoproject.com/ticket/33928#comment:1>
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/01070182aa3038ac-53e176d9-a3da-4a04-851c-5236e720fd17-000000%40eu-central-1.amazonses.com.
