No, nothing like that.

If youi consider the problems that occur with sequential INSERT operations into a table, the answer seems obvious... When you do sequential inserts, all insert activity occurs at the end of the table which forces the last active page to become a "hot spot" of contention. This means that if you have 20 processes (spids) trying to do insert operations, all of them have to fight for access to the last page in the table, and all of them have to handle the bookkeeping associated with page rollover when the final page becomes full and a new page becomes active at the end.

This was a common problem for Sybase and Microsoft in the late 1990s because DB2 and Oracle had already cracked the nut on this problem. Before Micorosft SQL 6.5 and Sybase 10.0, there was no viable solution for sequential insert operations. The Data Modeler or the DBA simply had to find a way around the problem.

GUIDs made the problem a non-issue, since their random nature ensured that even with 50 or 100 active processes (spids), the "hot spot" was negligable if it occurred at all.

For at least ninty-nine percent of the systems in place today, hot spots are a thing of the past and about as relevant as a spoke shave or a buggy whip. The problem is that for very large systems with really high insert volumes (even if those are just spurts in the stream of activity), hot spots can still be a point of contention.

Microsoft did a demo of this problem and a work-around for it at one of their regional "think tank" expos a couple of years ago. I might see if I can convince someone with a real world app to show a technology demo at PASS this year... Very few people hit this problem any more, but there are enough that do to make the demo worthwhile, and it would also help to dampen the myth that GUIDs are bad for performance when they can actually improve performance for large cases.

-PatP