Re: [PATCH] Refactoring of LWLock tranches

From: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: [PATCH] Refactoring of LWLock tranches
Date: 2015-12-24 12:20:01
Message-ID: 20151224152001.189bd6b4@lp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, 15 Dec 2015 13:56:30 -0500
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Dec 13, 2015 at 6:35 AM, andres(at)anarazel(dot)de
> <andres(at)anarazel(dot)de> wrote:
> > On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> >> On Sat, Dec 12, 2015 at 1:17 PM, andres(at)anarazel(dot)de
> >> <andres(at)anarazel(dot)de> wrote:
> >> > Here's two patches doing that. The first is an adaption of your
> >> > constants patch, using an enum and also converting xlog.c's
> >> > locks. The second is the separation into distinct tranches.
> >>
> >> Personally, I prefer the #define approach to the enum, but I can
> >> live with doing it this way.
> >
> > I think the lack needing to adjust the 'last defined' var is worth
> > it...
> >> Other than that, I think these patches look
> >> good, although if it's OK with you I would like to make a pass over
> >> the comments and the commit messages which seem to me that they
> >> could benefit from a bit of editing (but not much substantive
> >> change).
> >
> > Sounds good to me. You'll then commit that?
> Yes. Done!
> In terms of this project overall, NumLWLocks() now knows about only
> four categories of stuff: fixed lwlocks, backend locks (proc.c),
> replication slot locks, and locks needed by extensions. I think it'd
> probably be fine to move the backend locks into PGPROC directly, and
> the replication slot locks into ReplicationSlot. I don't know if that
> will improve performance but it doesn't seem like it should regress
> anything, though we should probably test that. I'm not sure what to
> do about extension-requested locks - maybe give those their own
> tranche somehow?
> I think we should also look at tranche-ifying the locks counted in
> just the lock manager locks and the predicate lock manager locks.
> That would get us to a place where every lock in the system has a
> descriptive name, either via the tranche or because it's an
> individually named lock, which sounds excellent.

There is a patch that moves backend LWLocks into PGPROC and to a
separate tranche. I did tests, and it doesn't regress and the same time
doesn't improve performance on my computer.

Ildus Kurbangaliev
Postgres Professional:
Russian Postgres Company

Attachment Content-Type Size
proc_lwlocks_tranche.patch text/x-patch 10.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ildus Kurbangaliev 2015-12-24 12:32:09 Re: Review: GiST support for UUIDs
Previous Message Aleksander Alekseev 2015-12-24 11:43:37 Re: WIP: bloom filter in Hash Joins with batches