#24507 closed Cleanup/optimization (duplicate)
Add the possibility to create only one index on CharField
Reported by: | Rodolphe Quiédeville | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.7 |
Severity: | Normal | Keywords: | index |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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
Change History (5)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
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 ?
comment:3 by , 10 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
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.
comment:4 by , 10 years ago
I'm compiling some stats on indexes usage on our production server. After that I'll open a discusion on the Devml, thanks !
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.