From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [WIP] shared locks |
Date: | 2005-04-19 01:53:38 |
Message-ID: | 200504190153.j3J1rc829706@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Yarra | 2005-04-19 02:16:07 | Re: SETOF function call |
Previous Message | Tom Lane | 2005-04-19 01:53:28 | Re: SETOF function call |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-04-19 03:14:03 | Re: Getting rid of the global timezone |
Previous Message | Tom Lane | 2005-04-19 00:00:57 | Re: [WIP] shared locks |