I have an app (0.96 so no select_related) that had a large initial data load consisting of a couple core tables and several foreign key relationships. I got a lot of mileage by caching just in a dictionary the foreign keys so that the ORM wasn't doing lots of redundant queries. I found the same strategy to work well when serving up the pages that viewed this data. In my case it was foods that had lots of nutrient entries but the basic nutrient info (name, symbol etc) was the same across each food. The actual nutrient value per serving is in a different table and not as easily "cached".
Since this data is unlikely to change, it is also a good candidate for memcached but I haven't gotten their yet. Also make sure you have your indexes tuned. For me it was something I thought of when working in pgAdmin and not while creating my model definitions. You can easily turn a 20 second query into a .2 second one when you eliminate table scans. On Sep 18, 3:43 pm, yezooz <[EMAIL PROTECTED]> wrote: > hi all, > > I'm sure many of you run high traffic websites in Django and I'm very > curious how you're avoiding performance hit caused by built-in ORM. > Select_related not always working and it's still might generate dozens > of select's. > Are you just running custom SQL queries with joins ? > > greetings --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
