Thanks Koen I had suspected such things would exist but couldnt find them. I will take a look at this. Looks like a neat addon which would greatly help my project turnaround time.
cheers Sam On Wed, Jan 6, 2010 at 11:07 PM, koenb <koen.bierm...@werk.belgie.be> wrote: > > On 31 dec 2009, 01:56, Sam Walters <mr.sam...@gmail.com> wrote: >> Thanks for the replies. >> >> Yes, there is the option of going to raw MySQL. However the project >> requirements mean i can't use raw SQL. (portability, readability) >> From what i can see using django's db API i have to execute the >> queries 500 times. >> I am very familiar with the query documentation and i know that >> select_related will prevent foward facing foreign keys translating to >> an individual sql queries which hit the db and would slow it down. >> >> Fact is even when i dont use 'select_related' the major performance >> problem occurs with the 'many-to-many' and 'reverse foreign' keys >> (some 75% of the performance penalty for my package method is with >> these) and only 20% can be solved by select_related. >> >> To be specific about how the multiplicities unfold: >> >> search_querySet is a Directory.objects.filter(... >> >> 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. >> >> thanks for the ideas. will continue testing and looking for answers >> >> -Sam >> >> On Thu, Dec 31, 2009 at 2:41 AM, Nick Arnett <nick.arn...@gmail.com> wrote: >> >> > On Wed, Dec 30, 2009 at 7:15 AM, Adam Playford <adam.playf...@gmail.com> >> > wrote: >> >> >> I'm not an expert on this, but a few thoughts. >> >> >> First, if I'm reading your message right, it sounds like your problem >> >> probably isn't with the query, but with how many times you're running >> >> it. >> >> > I'll echo that... the problem is not the database - the queries are as good >> > as it gets. The problem is running them repeatedly. >> >> > If all else fails, I'd replace those queries that execute 500 times with >> > raw >> > SQL that uses the IN operator to get the required rows. >> >> > E.g.: SELECT `common_addresstype`.`id`, `common_addresstype`.`adrtype` FROM >> > `common_addresstype` WHERE `common_addresstype`.`id` IN (1,6,8,52,173) >> >> > I imagine there's an ORM query that will do the same thing, but I know >> > MySQL >> > far better than I know Django. >> >> > Nick >> > > You can take a look at apps like django-selectreverse [1] or django- > batch-select [2] for some ideas to make this kind of optimisations > easier. > > Koen > > [1] http://code.google.com/p/django-selectreverse/ > [2] http://github.com/lilspikey/django-batch-select > > -- > 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. > > > >
-- 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.