On Sun, 2007-09-16 at 00:36 +0000, Rob Hudson wrote: > http://code.djangoproject.com/ticket/2465 > > I'm running into this and it makes sense to me that select_related > should do this right. I'm curious of Adrian's comment about this > involving a bunch of LEFT JOINs and why that's a bad thing?
It's a lot slower at the SQL level. Try it and see: put two joined tables into a database and allow the foreign key column to be NULL. Put in 100,000 rows or so. Now select a joined version of the tables using INNER joins and then LEFT OUTER joins. Time it. Notice the difference. Imagine you were doing that a few times a second. One thing we can add in the queryset-refactor, based on David Cramer's work, is allowing specifying the fields to use in a select_related(). The default case will still work as now, but this allows more fine-tuned control. In that case, if you specify a nullable column, we can join across it because you will have explicitly said you are willing to bear the pain (that wasn't something in David's original proposal, but it's a logical extension, since the syntax remains the same). This will be documented six ways from Sunday, which I fully expect people to not read. That gives people who want to accept the performance trade-off the ability to do so, without hurting the default case at all. Malcolm -- Works better when plugged in. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
