|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
> NUM_FIXED_LWLOCKS but not NUM_INDIVIDUAL_LWLOCKS. That's basically
> 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.
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
|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|