On Thu, Feb 24, 2011 at 11:15 PM, Jacob Kaplan-Moss <[email protected]> wrote: > On Thu, Feb 24, 2011 at 4:59 PM, mmcnickle <[email protected]> wrote: >> So there you have it, we have a small regression in performance for >> the most common case use, and a huge potential gain for the less used >> (and some would argue, badly designed) query. >> >> What do you think, is the gain worth the hit? Is it possible to have 2 >> different code paths depended on what column(s) the query is filtering >> on? > > Hm, I don't think it is. If get() is a performance concern, you should > have a unique index on the column. I think penalizing people "doing it > right" even a little bit is a bad idea. > > I *do* think we should add a note to the documentation -- in get(), > and/or in the database optimization doc -- about being sure that > you're only using get() on unique columns for best performance.
I concur. If you're retrieving by a column, you should be indexing on that column. Optimizing Django's retrieval code for the bad design case strikes me as equally bad design. I say document this and leave the code as is. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
