Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > The idea is that a tuple's Xmax can either be a real TransactionId > > (which is used normally like current CVS tip), or, if the infomask has > > HEAP_XMAX_SHARED_LOCK, a MultiXactId. > > Interesting idea. Would it be possible to invoke this mechanism only > when actually needed --- that is, the first locker of a given tuple > puts his plain TransactionId into Xmax (and also sets an infomask bit > indicating his intent to have a shared rather than exclusive lock), > and then the second locker to come along replaces the TransactionId > with a MultiTransactionId including himself and the first locker? > > This requires 2 infomask bits: 1 for shared vs exclusive lock and one > for whether the Xmax contains a TransactionId or MultiTransactionId. > But we have them available, and I think I like keeping those concepts > separate anyway. (Who's to say we wouldn't want to allow a > MultiTransactionId to hold an exclusive lock, someday?) > > The advantage of course would be substantially less overhead in the very > common case where there's no actual contention for the tuple.
Yes, that is certainly possible. Alvaro felt he wanted something simpler and that the two-bit case would add complexity, but I agree it would reduce overhead in the most common case. > > MultiXactIds are implemented using two SLRU areas and a couple of > > variables in ShmemVariableCache. We also XLog groups of them just like > > we do for Oids. > > So no need for expansible shmem storage? Might be the way to go. > I haven't read the patch yet but the idea sounds promising. Right. What he does is to use something like pg_subtrans to have a rolling window of current multi-xid sets and the idea is that most access will fall into a small window that is easily stored in the memory window. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
