On Wed, Jul 7, 2010 at 8:07 AM, Kevin Howerton <kevin.hower...@gmail.com> wrote: >> For a very high traffic project backed by 20+ DB servers > Slightly OT, but MySQL performance related... > > If you are write heavy, there's another issue that I imagine would > bring significant gains on a MyISAM setup of that proportion... and > possibly other databases to a lesser degree (the locking mechanisms > with MyISAM are different)
Yes - this is a well known limitation of MyISAM tables. This is a situation where you need to pick the right tool for the job; if you're on a write heavy site, MyISAM probably isn't going to be a good choice. > Basically, right now the ORM will UPDATE or INSERT based off of a > SELECT query it does when you hit save(). So even if the ORM should > already know it's an UPDATE it will run this logic and these queries. > > There's "force_update=True" which I imagine would skip the SELECT, but > I was looking into it because the logic here has some other > side-effects as well. > > One of the side effects is that if you change a PK, and try to save it > you end up with two rows. I guess the PK probably shouldn't be > mutable, or we can fix that logic and possible see some gains in > speed. If you've got any ideas on how to optimize the object saving process, we're happy to entertain them -- but keep in mind Django's backwards compatibility policy. Creating new objects by manually setting the primary key is a well established idiom. We can't eliminate this behavior without breaking backwards compatibility. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
