Re: LWLock contention: I think I understand the problem - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: LWLock contention: I think I understand the problem
Date
Msg-id 20020103101825N.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: LWLock contention: I think I understand the problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: LWLock contention: I think I understand the problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: LWLock contention: I think I understand the problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: LWLock contention: I think I understand the problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> I have thought of a further refinement to the patch I produced
> yesterday.  Assume that there are multiple waiters blocked on (eg)
> BufMgrLock.  After we release the first one, we want the currently
> running process to be able to continue acquiring and releasing the lock
> for as long as its time quantum holds out.  But in the patch as given,
> each acquire/release cycle releases another waiter.  This is probably
> not good.
> 
> Attached is a modification that prevents additional waiters from being
> released until the first releasee has a chance to run and acquire the
> lock.  Would you try this and see if it's better or not in your test
> cases?  It doesn't seem to help on a single CPU, but maybe on multiple
> CPUs it'll make a difference.
> 
> To try to make things simple, I've attached the mod in two forms:
> as a diff from current CVS, and as a diff from the previous patch.

Ok, here is a pgbench (-s 10) result on an AIX 5L box (4 way).

"7.2 with patch" is for the previous patch. "7.2 with patch (revised)"
is for the this patch. I see virtually no improvement. Please note
that xy axis are now in log scale.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: software license question
Next
From: Bruce Momjian
Date:
Subject: Re: Bulkloading using COPY - ignore duplicates?