Re: MultiXacts & WAL

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