[Django] #24507: Add the possibility to create only one index on CharField
Django
----------------------------------------------+--------------------
Reporter: rodo | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Database layer (models, ORM) | Version: 1.7
Severity: Normal | Keywords: index
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
As describe in the doc adding a db_index=True on CharField automatically
create 2 indexes on some backends to speedup LIKE queries. But in some
case the second index is not necessary when you know you always lookup on
the entire string.
Having a new option too only create simple index may be a good
improvement, actually on high volume database we need to maintain our
indexes outside of Django cause of that.
Regards
--
Ticket URL: <https://code.djangoproject.com/ticket/24507>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: rodo | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.7
(models, ORM) |
Severity: Normal | Resolution:
Keywords: index | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Duplicate of #24088. Do you have any data to substantiate the performance
motive? I don't think it would be difficult to use a `RunSQL` migration to
manually drop the index you don't want. This might be easier than
implementing a flag that only has specialized uses.
--
Ticket URL: <https://code.djangoproject.com/ticket/24507#comment:1>
Django
Reporter: rodo | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 1.7
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Easy pickings: 0 | UI/UX: 0
Comment (by rodo):
Sorry for the duplicate.
As a DBA point of view it's a little bit strange to maintain an index that
is never used, it's consumming IO on write operation and disk space. If I
look at our indexes statistics a part of them are never used, and it's
always these additionnal indexes.
I'm agree that is not difficult to remove them, but why createing them if
it's for removing them just after ?
--
Ticket URL: <https://code.djangoproject.com/ticket/24507#comment:2>
Django
Reporter: rodo | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 1.7
(models, ORM) |
Keywords: index | Triage Stage:
| Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => duplicate
Comment:
I'm not a DBA, so I don't have any performance numbers. Maybe you could
provide some. If so, could you open a discussion on the
DevelopersMailingList to ask to see if anyone thinks such an option to
disable those indexes is worthwhile? We can reopen one of the tickets if
so.
--
Ticket URL: <https://code.djangoproject.com/ticket/24507#comment:3>
Django
Reporter: rodo | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 1.7
(models, ORM) |
Severity: Normal | Resolution: duplicate
| Unreviewed
Easy pickings: 0 | UI/UX: 0
Comment (by rodo):
I'm compiling some stats on indexes usage on our production server. After
that I'll open a discusion on the Devml, thanks !
--
Ticket URL: <https://code.djangoproject.com/ticket/24507#comment:4>
Django
Reporter: rodo | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: 1.7
(models, ORM) |
Severity: Normal | Resolution: duplicate
| Unreviewed
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
[https://groups.google.com/d/topic/django-
developers/H2QFcQYsbo8/discussion Discussion on django-developers].
--
Ticket URL: <https://code.djangoproject.com/ticket/24507#comment:5>