From cb7dad1731f77e1a2a946c35263bb9aa7c6afd41 Mon Sep 17 00:00:00 2001 From: "Thomas G. Lockhart" Date: Thu, 3 Jun 1999 16:13:35 +0000 Subject: [PATCH] Make separate subsection for Vadim's MVCC notes. Add timing info for v6.5 on my linux box. --- doc/src/sgml/release.sgml | 154 +++++++++++++++++++++++--------------- 1 file changed, 95 insertions(+), 59 deletions(-) diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml index f8718c4aaca..d34e1c8f80f 100644 --- a/doc/src/sgml/release.sgml +++ b/doc/src/sgml/release.sgml @@ -39,9 +39,10 @@ other users. MVCC uses the natural multi-version nature of PostgreSQL to allow readers to continue reading consistent data during writer activity. Writers continue to use the compact pg_log transaction - system. This is all preformed without having to allocate a lock for + system. This is all performed without having to allocate a lock for every row like traditional database systems. So, basically, we no - longer have table-level locking, we have something better than row-level + longer are restricted by simple table-level locking; + we have something better than row-level locking. @@ -134,59 +135,61 @@ - - Because readers in 6.5 don't lock data, regardless of transaction - isolation level, data read by one transaction can be overwritten by - another. In the other words, if a row is returned by - SELECT it doesn't mean that this row really exists - at the time it is returned (i.e. sometime after the statement or - transaction began) nor that the row is protected from deletion or - updation by concurrent transactions before the current transaction does - a commit or rollback. - + The new Multi-Version Concurrency Control (MVCC) features can + give somewhat different behaviors in multi-user + environments. Read and understand the following section + to ensure that your existing applications will give you the + behavior you need. - + + Multi-Version Concurrency Control - To ensure the actual existance of a row and protect it against - concurrent updates one must use SELECT FOR UPDATE or - an appropriate LOCK TABLE statement. This should be - taken into account when porting applications from previous releases of - Postgres and other environments. + + Because readers in 6.5 don't lock data, regardless of transaction + isolation level, data read by one transaction can be overwritten by + another. In the other words, if a row is returned by + SELECT it doesn't mean that this row really exists + at the time it is returned (i.e. sometime after the statement or + transaction began) nor that the row is protected from deletion or + updation by concurrent transactions before the current transaction does + a commit or rollback. + - + + To ensure the actual existance of a row and protect it against + concurrent updates one must use SELECT FOR UPDATE or + an appropriate LOCK TABLE statement. This should be + taken into account when porting applications from previous releases of + Postgres and other environments. + - + + Keep above in mind if you are using contrib/refint.* triggers for + referential integrity. Additional technics are required now. One way is + to use LOCK parent_table IN SHARE ROW EXCLUSIVE MODE + command if a transaction is going to update/delete a primary key and + use LOCK parent_table IN SHARE MODE command if a + transaction is going to update/insert a foreign key. - Keep above in mind if you are using contrib/refint.* triggers for - referential integrity. Additional technics are required now. One way is - to use LOCK parent_table IN SHARE ROW EXCLUSIVE MODE - command if a transaction is going to update/delete a primary key and - use LOCK parent_table IN SHARE MODE command if a - transaction is going to update/insert a foreign key. - - - - - Note that if you run a transaction in SERIALIZABLE mode then you must - execute LOCK commands above before execution of any - DML statement - (SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO) in the - transaction. - - - - - - - These inconveniences will disappear when the ability to read durty - (uncommitted) data, regardless of isolation level, and true referential - integrity will be implemented. - - - - + + + Note that if you run a transaction in SERIALIZABLE mode then you must + execute the LOCK commands above before execution of any + DML statement + (SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO) in the + transaction. + + + + + These inconveniences will disappear in the future + when the ability to read dirty + (uncommitted) data (regardless of isolation level) and true referential + integrity will be implemented. + + @@ -2541,22 +2544,55 @@ Initial release. - -Timing Results + + Timing Results - -These timing results are from running the regression test with the commands + + These timing results are from running the regression test with the commands - + % cd src/test/regress % make all % time make runtest - - - - Timing under Linux 2.0.27 seems to have a roughly 5% variation from run - to run, presumably due to the scheduling vagaries of multitasking systems. - + + + + Timing under Linux 2.0.27 seems to have a roughly 5% variation from run + to run, presumably due to the scheduling vagaries of multitasking systems. + + + + v6.5 + + + As has been the case for previous releases, timing between + releases is not directly comparable since new regression tests + have been added. In general, v6.5 is faster than previous + releases. + + + + Timing with fsync() disabled: + + + Time System + 02:00 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486 + + + + + Timing with fsync() enabled: + + + Time System + 04:21 Dual Pentium Pro 180, 224MB, UW-SCSI, Linux 2.0.36, gcc 2.7.2.3 -O2 -m486 + + + For the linux system above, using UW-SCSI disks rather than (older) IDE + disks leads to a 50% improvement in speed on the regression test. + + + v6.4beta