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.
