>>>>> "Doug" == Doug Salot <dsalot@stripped> writes:
Doug> On Tue, 31 Aug 1999, Michael Widenius wrote:
>> It's only when you mix many slow queries with writes and can't let the
>> readers wait as MySQL will not perform as good as Oracle)
Doug> Is this because MySQL does table locking and Oracle does row locking, or
Doug> is it that Oracle does some sort of predictive query prioritizing?
Neither. Note that row locking in the application is something one
should always avoid at all costs (it will normally not work in the long run).
Row locking at the database level is also something that 'is not good' ,
but not as bad as application locking.
The main difference between MySQL and Oracle in the above case is that
when you have a efficient implementation of transactions, two threads
can update the same row at the same time without 'any problems'. The
transaction that ends first will have the row updated while the other
one has to do a rollback.
This will of course instead require a huge amount of memory in some cases,
but it in the case of few updates + long slow queries this is a very
good approach.
Doug> In any case, is this something that will improve in MySQL in the
Doug> near-term?
In most application the table locking problem isn't that big and it's
not that hard to go around it; If you can avoid the case of slow
selects + updates then table locking is superior to row locking (or
transactions).
It's hard to get the best of both words; For some kind of applications
MySQL is better than Oracle and for others Oracle is better.
(By the way; If you look at current job applications, MANY of these
asks for competence in Oracle AND MySQL !)
In MySQL this will be fixed when we have transactions, which may
happen a lot earlier than we originally planed...
Regards,
Monty
