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
> 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

  Bruce Momjian                        |               |  (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

Reply via email to