Re: Microsoft destroys TPC-C records!

On 6 Apr 2000 17:38:26 GMT, Norris <jcheong_at_cooper.com.hk> wrote:

>That is the point:
>
>With page-, multiple page-, and table-level locking, fewer system resources are used than with row-level locking.
>
>SQL Server is designed to AUTOMATICALLY maximize the trade-off between concurrency and performance and system resources, to give the optimal level of lock specificity (row, page, multiple page, or table) for all database operations.
>
>Of course, you can MANAULLY speed up the operation.
>

Norris you don't get it, do you?

With a database where writers block readers, if you have a locking mechanism that does what you claim is good, you end up with a table that is not readable at all! Got it?

I could go on describing to you all the possible horrible cases. They have been verified on real databases that used exactly the same approach of lock escalation under control of the "all-knowing-engine".

Got news for you: the engine might know what the app IS doing, but it has NO CLUE on what the application mix MIGHT be doing 10 minutes from now. So the whole thing will never work.

Been there, been done, been proven that it is a DISASTER in mixed high-loads. Ages ago. It's only the MS "geniuses" that still haven't clicked into it. Everybody else in the industry has given it up way long ago, or fallen by the wayside.

Doesn't it even register with you why these "famous" thousands of tps in benchmarks are of ONE single mix per database?

Since when can anybody afford to run a single type of application per database node?

You'd have to OFFER the darn thing for FREE for the TCO to come down in real life....

As I said: get a copy of ORACLE, and check out how MS's claim that row locking slows down large updates is totally FALSE. Don't confuse MS's crap implementation of row locking with what can be done. And has been done in ORACLE.

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Fri Apr 07 2000 - 00:00:00 CDT