Re: [PATCH] Refactoring of LWLock tranches
От | Ildus Kurbangaliev |
---|---|
Тема | Re: [PATCH] Refactoring of LWLock tranches |
Дата | |
Msg-id | 20151224152001.189bd6b4@lp обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactoring of LWLock tranches (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Refactoring of LWLock tranches
|
Список | pgsql-hackers |
On Tue, 15 Dec 2015 13:56:30 -0500 Robert Haas <robertmhaas@gmail.com> wrote: > On Sun, Dec 13, 2015 at 6:35 AM, andres@anarazel.de > <andres@anarazel.de> wrote: > > On 2015-12-12 21:15:52 -0500, Robert Haas wrote: > >> On Sat, Dec 12, 2015 at 1:17 PM, andres@anarazel.de > >> <andres@anarazel.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. -- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: