But you would still need to pull the password from the table to do the comparison in the "WHERE" clause. If you over-indexed and captured the password as part of the index, the database only has to read the index to figure if your row matches. This helps eliminate a read on a failed login attempt (reducing locks, etc) and also would help on a successful login attempt if you're only pulling out those two columns. Django (I think?) pulls out all the columns so it probably needs to read the table anyway on a successful attempt. Minor performance enhancement for most sites but easy to implement.
The pk index problem is definitely a much bigger deal for those who aren't going around pruning indexes. On Apr 29, 9:24 pm, David Cramer <[EMAIL PROTECTED]> wrote: > +1 on pk index fix > > as for auth_user, username being indexed would be good, but I believe > the hash is calculated completely outside of SQL, so there's no need > to index password. > > On Apr 29, 12:15 pm, Ed Menendez <[EMAIL PROTECTED]> wrote:> When creating a > one to one table or a table with a compound key.. > > Django wants to create an index for the PK/alternate key and also > > another index on the same column(s) because it's a FK. For example, if > > I have: > > > class League(models.Model): > > name = models.CharField(max_length=50) > > > class Season(models.Model): > > name = models.CharField(max_length=50) > > > class LeagueSeason(models.Model): > > league = models.ForeignKey(League) > > season = models.ForeignKey(Season) > > > In LeagueSeason it will create the PK index on league + season (which > > is correct), but then it will create an index on league and another on > > season. The one on season should be created, but the one on league > > should NOT be created since the PK index can be used. One to ones are > > a simpler example and the 2nd index should never be created. > > > Better index on auth_user? > > auth_user.username might as well have username and password in the > > index since you usually query both and if you only query one, that's > > ok, the index will still work. Since the typical use case for that is > > login via username/pw, you never have to hit the table can just use > > the index to pull the password. Saves an extra read to the database. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
