On 31 Gru 2009, 01:56, Sam Walters <mr.sam...@gmail.com> wrote: > for s in search_querySet: > address_info = s.address_set.all() #.select_related(depth=2) - > yes i can/will put select related here but it really does not help > that much 20% tops > #address_info is usually 2-3 rows from an address table > for a in address_info:#.select_related(depth=2): > if a.addresstype.adrtype == 'Physical' and > a.addradmin.addr_enabled == True: > #further reduction in the number of rows which we need to > get values from. > related_phone=a.phone_set.all() > related_email=s.email_set.all() > #phones and emails are a small number of rows 2-3 tops > > It is these lines which produce the performance hit. > I cant see a way of using django's query language to avoid having to > descend into each of the 500 'directory' objects because of the > necessity to get all rows from the related tables in phones an emails > and to inspect the type of 'address' object. >
I solved very similar problem by creating database VIEWs with data I needed, wrapping those VIEWs with unmanaged Django models and then using simple .filter(...)-s. Re those VIEWs, they are SELECTs with JOINs, which effectively produce up to a few rows for single object (e.g. if you have person with 3 phone numbers, you're getting 3 rows), but it turns out to be much more efficient to process/merge that in Python code than to issue hundreds of SQL queries. -- Tomasz Zielinski http://pyconsultant.eu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
