During the early 1970's there was great enthusiasm for database-machines, special hardware that would somehow solve the performance problems that plague database systems to this day. The theory was that if the brilliant database researchers could just bypass the file system and operating system, if they could just get to the bare metal, things would be ten times faster. Being an OS guy at heart, I was puzzled that these folks thought they could do IO better than we could - they did not seem to understand what interrupts were. Not just that, they seemed not to appreciate all the subtleties of error handling, multi-programming, multi-processing, security, and so on. One day I had a epiphany: I read the Bitton-DeWitt-Turbyfill paper. Suddenly, I realized what was going on: I had been working on what would now be called online-transaction-processing problems, while all my database machine friends were working on what would now be called data mining. They were doing joins, they were scanning the whole 4 MB database, while I was doing tiny transactions on giant (500MB) at the time databases. I was worried about security, concurrency, recovery, manageability, while they were worried about sequential scans, aggregates, and especially joins.
To crystallize this difference I wrote a puff-piece: ``A Measure of Transaction Processing'' that described an OLTP transaction that eventually gave rise to the Transaction Processing Performance Council and the TPC-A benchmark. It included a user-level mini-batch transaction (copy 1,000 records) and a batch transaction (sort a million records). Unfortunately, it left out a backup-restore job. This paper circulated among a large crowd. About 25 people added something. To avoid the legal hassles of getting the ATT and DEC and Xerox and IBM and Tandem lawyers to agree, we published it under the pseudonym Anon Et Al. The paper appeared in April Fools Day issue of Datamation in 1985. To this day, we award the SIGMOD Sort trophies on that date (see http://www.research.microsoft.com/barc/SortBenchmark/DEFAULT.htm). Once in a while I got letters to Dr. Anon (the Tandem mail room knew and enjoyed the joke).
The irony of this story is that the "Wisconsin" benchmark eventually spawned the TPC-D benchmark. TPC-D now is center-stage in the great DBMS performance wars.
Copyright © 1999 by the author(s). Review published with permission.