Re: On more efficient use of QuerySets
James Bennett wrote: > The 'select_related' method[1] may be what you're looking for; it > selects related objects up-front in the same query, so that later > access doesn't go back and hit the DB again. Yes, I'm doing this where it makes sense. What I'm looking for is whether there is a way to say these types of things without making another database call: * Of this list of Response objects which I already have, give me a list where this filter condition is true. * Of this list of Content objects, remove those where this filter condition is true. Would iterating over the list and checking each object be faster than simply making another db call? Maybe I'm making more of an efficiency issue out of this than it really is, but I thought I'd at least investigate ways to optimize what we have. Thanks, Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: On more efficient use of QuerySets
On 4/4/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > What would be more efficient would be if I could get all responses for a > particular user, then pluck the particular variables out of that data > set as/when I need them. 1 SQL call. Is that possible? Are there > memory tradeoffs? There could be potentially on the order of 100 > responses per user and each of those is a Response object. Is there a > way to estimate memory footprint for that? Is this even worth the > effort -- the individual queries are about .001s, and in total about > 0.065s for the particular page I'm looking at. The 'select_related' method[1] may be what you're looking for; it selects related objects up-front in the same query, so that later access doesn't go back and hit the DB again. But keep in mind that this isn't always the best solution; some databases actually prefer getting lots of small queries to getting one or two really complex ones (e.g., MySQL is optimized for "lots of small queries", while Postgres tends to do better with one complex query). You'll definitely want to do some profiling to find out which option performs better for your database. [1] http://www.djangoproject.com/documentation/db-api/#select-related -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
On more efficient use of QuerySets
Fellow Djangonauts, Here at my work[1] we've built a number of web-based educational websites in Django now. I'm analyzing the number of SQL calls and am realizing that the number is higher than I'd like. My main question is around whether or not I can do a bulk query to get most of the data I need, and then do filtering or quick searching of the resulting list of objects. I'm thinking that it can't be done without another database call but you guys are smart and creative, so I'm sure there are other ways that I haven't thought of. :) Our data resides in a custom built content management system built in Django. We have a data model for content and media and questions (forms) and user responses to those questions. Here's a typical scenario that leads to extra SQL calls: The user has traversed a subset of the program and has answered questions or hit triggers which set responses to track the user. They hit a page which tailors content based on their previous responses or triggers. If there are a number of variables that come into play to tailor content to this user we get those with the usual ORM and filter by what we need. When I look at the SQL calls made during page creation, I see a lot of: SELECT value FROM responses WHERE varname='blah' and user_id=1; What would be more efficient would be if I could get all responses for a particular user, then pluck the particular variables out of that data set as/when I need them. 1 SQL call. Is that possible? Are there memory tradeoffs? There could be potentially on the order of 100 responses per user and each of those is a Response object. Is there a way to estimate memory footprint for that? Is this even worth the effort -- the individual queries are about .001s, and in total about 0.065s for the particular page I'm looking at. I've thought about the idea of turning the resulting list into a dictionary keyed by varname so I can get the Response object by varname. But there are other scenarios where I'd like to filter the data in different ways. So in a general case I'm looking for other ideas. Thanks, Rob [1] Oregon Center for Applied Science (http://www.orcasinc.com/) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
