I should have refreshed my memory before describing the disadvantages of MVCC. I don't believe the main problem is slow updates, rather it is the fact that writer conflicts result in all but one transaction being aborted; the prize goes to the early bird. This behavior is not friendly to long running transactions, because it is likely that they will be aborted. There is a discussion of the concepts in "Transaction Processing: Concepts and Techniques" by Jim Gray and Andreas Reuter. See the section on Time Domain Addressing. The book, written in 1993, mentions that PostgreSQL, among others, supports Time Domain Addressing. (Trivia niblit: Jim Gray now heads up the SQL Server team at Microsoft. Billy boy opened a special lab on the east coast as an incentive for him to join up.) I think we are thoroughly off topic now. Mike Bresnahan > -----Original Message----- > From: tclug-list-admin at mn-linux.org > [mailto:tclug-list-admin at mn-linux.org]On Behalf Of Mike Bresnahan > Sent: Wednesday, November 07, 2001 1:55 PM > To: tclug-list at mn-linux.org > Subject: RE: [TCLUG] PostgreSQL Advocacy (was Re: <TROLL> (was ...)) > > > > Exerpt from http://www3.us.postgresql.org/features.html > > > > Multi-Version Concurrency Control (MVCC) for highly scalable > > concurrent applications: > > * Readers do not block writers and writers do not block readers. > > * "Better than row-level locking." > > * Various row and table level locks are available as well. > > > > Detail found at > > http://www3.us.postgresql.org/users-lounge/docs/7.1/user/mvcc.html > > "Better than row-level locking" sounds like marketing spin to me. > > Just in case it's not already known to everyone reading, MVCC nor > row-level-locking are the best in all cases. Both add overhead above and > beyond standard multi-reader/one-writer page level locking. If your app > doesn't make up for this by gaining more concurrency, then it will run > slower and/or take up more disk space. For example, a single user > application will certainly not gain anything from using any kind of > concurrency control mechanism. Additionally, MVCC is geared toward > applications with more readers than writers. Each write requires the data > to be copied and thus writes take a long time. If you have more writers > than readers, then you are likely to not be served well by MVCC. However, > it is cool that PostgreSQL provides the MVCC option. (Trivia > niblit: Object > Design's ObjectStore also offers MVCC.) > > Mike Bresnahan > > > _______________________________________________ > Twin Cities Linux Users Group Mailing List - Minneapolis/St. > Paul, Minnesota > http://www.mn-linux.org > tclug-list at mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-list