David Earl wrote: > On 12/01/2009 13:05, Tom Hughes wrote: >> David Earl wrote: >> >>> While what Tom says may help performance, I don't think it is why >>> things are running disparately slowly at the moment. >> Oh yes it is... > > Table locks would indeed cause a problem, as you say (I've never > disagreed). But it isn't supposed to be locking at all.
Why do you think that? It's a relational database so of course it does locking. Even MySQL isn't that stupid. > And nothing's changed since Christmas, whereas the collision of the > multiple updates is something that I know has been happening recently. Part of what may have changed is that I've got bored of logging on to the machine and killing the long running queries, so when people complain about it I tell them to wait. > Please, Tom, I do know how and why locks and deadlocks work. Wjere I am > wrong though is that MySQL has some per-command locking internally that > I wasn't aware of, rather than LOCK TABLE which I was (intending to be) > avoiding. I've just gone back and re-read the relevant section in the > MySQL documentation, and I still don't think it is clear. I was assuming > by locks, they meant those established by LOCK... I'm sorry if I > misunderstood that before, that you can't in fact turn off locking entirely. LOCK TABLE is just a convenience, and not something that would normally be used as all command will do the locking they need. The only reason for using it is when you want to lock a group of tables before you start doing a batch of work. Tom -- Tom Hughes ([email protected]) http://www.compton.nu/ _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
