What foods MVCC?

PostgreSQL Every programmer who never made a multi-user application must have been frustrated because of the lock can cause the user to wait or even deadlock and the application hangs. although the databases used are already using table-level, page-level, column-level or row-level locking, the same problem persists: SELECT by one user nge-block UPDATE by another user until the transaction is the first user is finished, and vice versa UPDATE one user nge-block SELECT by another user until the first user transaction is completed.

But for those who are already using PostgreSQL certainly know that problems like the above will not occur for at PostgreSQL no advanced feature called Multi-Versioning Concurrency Control (MVCC) so SELECT never nge-block UPDATE, and UPDATE never nge-block SELECT.

Named Multi-Versioning version of the data being viewed by a user (or a single transaction) will be different from the data seen by the user is in another transaction. This means that data changes that occur in the database through UPDATE, INSERT, or DELETE made by one transaction will not be visible to other users of different transactions. The new changes will be seen when it is already happening COMMIT.

A simple example below shows the difference between the low-level locking in traditional database systems with MVCC in PostgreSQL.

                            SELECT headline FROM news_items

This statement reads data from a table named news_items and displays all the rows in a column called headlines. For databases that use a low-level locking, the SELECT statement would not work and had to wait if there are other users simultaneously insert (INSERT) or update (UPDATE) data in the table news item. Transactions that change the data holds the lock on the row that changed and therefore all the rows of the table can not be displayed. Users waiting for ter-block can be frustrating because they do not know when the lock will be released. Imagine if the users do forget COMMIT data changes and leave the computer for lunch.

In PostgreSQL, under any circumstances, users can always see table news_items. No need to wait lock is released, even if some users who enter and update data in a table. When a user runs a SELECT query, PostgreSQL display a snapshot, or version, of all the data that is done before the changes made by other users. Update any data that is part of the transaction dilakuka by another user will not be visible. quite reasonable, does not it?