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
