>>>>> "Andy" == Andy <andy1@stripped> writes:
Andy> At 11:38 PM 12/29/99 +0200, you wrote:
Andy> Hi Monty,
>>
Andy> I remember you said a while ago that 3.23.9 will allow
Andy> concurrent read and write (not just INSERT, but presumably
Andy> REPLACE & UPDATE?). Is that still the plan? Your saying
>>
Andy> "We are not anymore adding any features..."
Andy> makes me wonder. Concurrent read/write would *really* help me.
>>
>> Sorry, I have never said that we will have concurrent replace & update in
>> the near future. With MyISAM and HEAP it would introduce the problems
>> of dirty reads and we are not yet prepared to allow the use of
>> optional dirty reads..
>>
>> We are however working on adding a new table handler that will
>> supports transactions. This handler will have smaller granularity on
>> locks, but if you do a GROUP BY on everything, you will still get
>> something similar to table locks. (This is common on most systems that
>> uses page locking).
>>
>> As the above is done by just modifying a new class, this will not make
>> the 3.23 server more instable (it may only be a bit more instable IF
>> you use this new table type...)
>>
Andy> I must have misunderstood you then. Sorry. Could you clarify what
Andy> you meant by "a solution for the general case" in an earlier email
Andy> which I'm quoting below:
>> Anyway, in MySQL 3.23.7 we have solved the case where you have INSERTS
>> mixed with SELECT's (which is the common case in many web applications
>> where you just log things and do selects from them).
>>
>> In MySQL 3.23.9 we *should* have a solution for the general case,
>> which *should* be as good or better than in any of the other SQL
>> engines....
>>
See my previous answer; The page locking, when using transactions, is
better than table locking for a lot of applications (but not
as good as the new insert_delayed handling...)
Regards,
Monty
