Hello,
the fix for https://code.djangoproject.com/ticket/27241 caused significant
performance drop for my project, because it pretty much prevents posgresql
from using indexes on the particular query. I use unmanaged tables because
Django is used to display data from another project's database,
You asked me to join in on this conversation as I had an issue using Django
1.11. My third party apps do not yet all support Django 2.0.
I have an unmanaged model that is connected to a view in PostgreSQL. I
attempted to create an annotated version of the model manager using the
.annotate() m
Is there any reason not to query the models on startup to determine which
ones support the optimization and which do not (naively, which are proper
tables and which are views, but perhaps postgresql can provide the
information instead of relying on heuristics which could change in any
release)?
Thanks for that extensive write up!
As the reporter of #27241 it seems I would be arguing against my own self
interest when I say that I'm not in favour of the patch, but my reasonings
are as follows:
* The current behaviour is preferable in the vast majority of cases, only a
couple of project
> Therefore I'd favor we keep the current adjustment in the master branch
as it
> restores backward compatibility but I don't have strong feelings about
reverting
> it either if it's deemed inappropriate.
Fixing the crash is the number 1 priority in my opinion, as it broke
something that used t
Hello fellow developers,
As some of you may know PostgreSQL 9.1 added support for GROUP'ing BY
selected table primary keys[0] only. Five years ago it was reported[1] that
Django could rely on this feature to speed up aggregation on models backed
up by tables with either many fields or a few large
