I don't think anybody has anything against making values() or values_list() queries faster. The question is purely about implementation. If you can offer something that is faster than the current code without introducing backwards incompatibilities or making the code a lot more complex, then such a change has a good possibility to be merged.
You can likely find some conditions when you can fast-path the results_iter() handling for values_list() querysets. It is certain that you can't do this in all cases. If you want to proceed with the implementation, the best way forward is to just run the full Django test suite against your changes. It will point out a couple of cases where you'll see why certain things are done (from_db_value() for example). Of course, you should work against Django's master branch. - Anssi On Mon, Nov 16, 2015 at 3:02 PM, Cristiano Coelho <cristianocc...@gmail.com> wrote: > I would like to add, that minor change on a critical query meant an increase > from 37 to 47 requests per second on a benchmark test with apache, that's a > 22% improvement that will be bigger on larger results (this was just with 700 > rows result set), compared to using some pagination with a limit of 100 that > raises the requests per second value to almost 200, there's a clear > bottleneck in there. > > Looking at the code of values list queryset, maybe is it possible to replace > the call of results_iter to directly use execute_sql(MULTI) avoiding all the > unnecessary ifs and loops that results_iter does that is mainly useful for > other query set objects, but not for values list. I did a test with the above > and values list queries were performing as good as using directly a django > cursor, but not as good as using as_sql() and then the cursor, but very close. > > What would be the issues of adding such and optimization to values list? I'm > even thinking of manually monkey patching it so all my values list queries > are improved in my project, since I use values list most of the time due to > performance reasons since building objects on large results is extremely > slow, blame on python sadly. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/7729d524-1449-48a4-92b2-72b866c19e7c%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALMtK1EBv1e%2BDnoWk5qRyKKbwHhaHPD%3D%2BtaTt-HCgptuTEhNBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
