I am pretty sure the IN() performance issue in MySQL was fixed 5.5, and 5.6/5.7 certainly don't have an issue with IN() whether you use a bunch of values or a subquery.
Cheers François On Nov 8, 2013, at 2:15 AM, akaariai <akaar...@gmail.com> wrote: > On Friday, November 8, 2013 8:44:09 AM UTC+2, Robin St.Clair wrote: > Anssi > > The last time I checked the use of IN, all the records from the database in > the query were brought back to the workstation, rather than being processed > on the backend and only the results returned to the workstation. > > Have there been changes that carry out the entire query on the backend? What > has changed to cause you to prefer the use of the IN statement? > > Django has had the ability to execute __in=qs in single query for a somewhat > long time (from Django 1.2 maybe?). > > It is true that __in lookup against a large list of values is often a bad > choice even if you have the values at hand. Unfortunately this doesn't apply > to all databases, for example older versions of MySQL do not handle > subqueries well. > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/f3428fda-e4be-4d75-8626-a95bd20f66c8%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
