my understanding was it used more resources than read committed because it keeps track of the version id of rows selected so far in a transaction, "transaction-level consistency", so it has the potential to do the xmin co-selecting , and checking, if it were a transaction isolation level in postgres. google found my reference, and the reference mentioned it was different from serializable. On Mon Oct 15 9:09 , "Trevor Talbot" sent: >On 10/15/07, Syan Tan wrote: > >> >Also keep in mind that MVCC is not the only way to implement >> >transactions; pure locking is more common in other databases. In the >> >locking model, most transactions prevent others from writing until >> >after they are finished. Rows simply can't have different versions >> >(and of course concurrent performance is awful). >> >> what about postgresql doing something like snapshot isolation level as per >> the enemy M$ ? > >SQL Server is normally a pure locking database; from what I can tell, >its snapshot isolation level adds a limited form of MVCC above that, >making its concurrent behavior closer to PostgreSQL's: >http://msdn2.microsoft.com/en-us/library/ms345124\(d=printer\).aspx ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
