On Sat, 17 Jun 2006, paolo romano wrote:
* Reduced I/O Activity: during transaction processing: current workloads
are typically dominated by reads (rather than updates)... and reads give
rise to multixacts (if there are at least two transactions reading the
same page or if an explicit lock request is performed through
heap_lock_tuple). And (long) transactions can read a lot of tuples,
which directly translates into (long) multixact logging sooner or later.
To accurately estimate the possible performance gain one should perform
some profiling, but at first glance ISTM that there are good
potentialities.
Read-only transactions don't acquire shared locks. And updating
transcations emit WAL records anyway; the additional I/O caused by
multixact records is negligable.
Also, multixacts are only used when two transactions hold a shared lock
on the same row.
* Reduced Recovery Time: because of shorter logs & less data
structures to rebuild... and reducing recovery time helps improving
system availability so should not be overlooked.
I doubt the multixact stuff makes much difference compared to all other
WAL traffic.
In fact, logging the multixact stuff could be skipped when no two-phase
transactions are involved. The problem is, you don't know if a transaction is one
phase or two phase before you see COMMIT or PREPARE TRANSACTION.
- Heikki
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
