home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / benchmar / 1354 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  2.3 KB
  1. Xref: sparky comp.benchmarks:1354 comp.databases:6482 comp.databases.oracle:1457 comp.databases.theory:437
  2. Newsgroups: comp.benchmarks,comp.databases,comp.databases.oracle,comp.databases.theory
  3. Path: sparky!uunet!sun-barr!ames!pasteur!olympus.CS.Berkeley.EDU!devine
  4. From: devine@olympus.CS.Berkeley.EDU (bob devine)
  5. Subject: Re: Oracle TPC Benchmarks and "discrete transactions"
  6. Message-ID: <1992Sep1.211955.10539@pasteur.Berkeley.EDU>
  7. Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
  8. Nntp-Posting-Host: olympus.berkeley.edu
  9. Organization: University of California, at Berkeley
  10. X-Newsreader: Tin 1.1 PL3
  11. References: <1992Aug28.165809.17127@tandem.com>
  12. Date: Tue, 1 Sep 1992 21:19:55 GMT
  13. Lines: 33
  14.  
  15. levine_charles@tandem.com (Charles Levine) writes:
  16. : ---------------------------------------
  17. : - Are discrete transactions a good idea?
  18. : - Is this an innovation that other database vendors should pursue?
  19. : - Given their limited nature and the user sophistication required,
  20. :   do discrete transactions make sense in the relational model?
  21.  
  22. It is obvious that Oracle has invented discrete transactions as a
  23. way to generate higher TPC numbers.  While these probably don't
  24. break the letter of the TPC rules, they do break its spirit!
  25.  
  26. The bigger question is if a special, slimmed-down transaction
  27. semantics are required for real-world cases rather than for the
  28. semi-artificial TPC example.  Are regular transactions too "heavy"
  29. or too general purpose for a class of problems that could more
  30. efficiently be solved with a "lite" transaction?
  31.  
  32. My gut feeling is that: Yes, "lite" transactions might be a valuable
  33. addition to the bag of tricks used in database.  The optimizer could
  34. use them as a hint to avoid some locking or logging that would
  35. normally be done for regular transactions.
  36.  
  37. What needs to be done is a tight analysis of what benefits could
  38. result from adding more complexity to the db programmer's life (and
  39. to the folks who implement a db's optimizer!).  If only a few
  40. percentage improvement is possible with a general "lite" transaction
  41. then it is not worth the bother.  However, the Oracle-7 numbers show
  42. that some hefty benefit is possible with their TPC-oriented transaction
  43. so a more general "lite" transaction might produce a > 10% gain.
  44. In this case it is probably worth the bother when tweaking the last
  45. bit of performance out of an large application.
  46.  
  47. Bob Devine
  48.