> > Without specifics, it's a little difficult to say for certain, but one > of the reasons for the switch to newforms and newforms-admin was to > eliminate some very expensive querying behavior in the manipulators > behind forms. This wasn't a matter of one big query that was expensive > - but you could easily end up with a very large number of very small > queries. As your user base expands, it's entirely possible that the > flood of little queries is adding up and slowing down the site. > > The other obvious place to look is where Karen noted - Foreign keys > with very large selection sets. The raw id field option is one way to > address this; another approach is to write a custom widget that > doesn't try to load the entire selection set. >
Thanks, despite my lack of detail this is a good pointer to identify what to change. I have several tables which use reference an FK on a larger table. Some of the slower ones don't however, so I'll need to delve a bit further to see what might be causing it. I'll go ahead as planned on the Django update and see if this delivers any improvements. With regards to your suggestion of using the raw id field, is this a Django option, or did you mean changing the FK to using a simple ID field. I've been through the docs and can't see any reference to a raw_id option, although recall seeing it mentioned on some occasion whilst trawling. If an option, can you give me a link? Thanks and regards, Tim --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
