dhepner@hpisod2.hp.com@canremote.uucp (dhepner@hpisod2.HP.COM) (12/21/89)
From: dhepner@hpisod2.HP.COM (Dan Hepner) Subj: Client/server processes and implementations Orga: Hewlett Packard, Cupertino From: jwc@unify.uucp (J. William Claypool) > >Quite the opposite. I was suggesting that such a transaction is not >entirely atypical. As a result, row level locking IS required and there >is more potential for contention in the lock management routines. > >Actually, the big problem with some DBMS systems is that there is a >single insert point when extending a table. Hence the games some >vendors have had to play with multiple history tables for TP1. The freedom to "play games with multiple history tables" is being codified in TPC-A. The rationale seems to be that if the benchmark insisted on a single history table, then most existing products would immediately become bottlenecked at precisely that place. If there were justification for that bottleneck being taken taken that seriously, it wasn't discovered. Dan Hepner --- * Via MaSNet/HST96/HST144/V32 - UN Databases * Via Usenet Newsgroup comp.databases