Hello, At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev <i.kurbangal...@postgrespro.ru> wrote in <55ae2cd9.4050...@postgrespro.ru> > On 07/21/2015 01:18 PM, Andres Freund wrote: > > On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote: > >> /* > >> * Top-level transactions are identified by VirtualTransactionIDs > >> * comprising > >> diff --git a/src/include/storage/lwlock.h > >> b/src/include/storage/lwlock.h > >> index cff3b99..55b0687 100644 > >> --- a/src/include/storage/lwlock.h > >> +++ b/src/include/storage/lwlock.h > >> @@ -58,6 +58,9 @@ typedef struct LWLock > >> #ifdef LOCK_DEBUG > >> struct PGPROC *owner; /* last exlusive owner of the lock */ > >> #endif > >> + > >> + /* LWLock group, initialized as -1, calculated in first acquire */ > >> + int group; > >> } LWLock; > > I'd very much like to avoid increasing the size of struct LWLock. We > > have a lot of those and I'd still like to inline them with the buffer > > descriptors. Why do we need a separate group and can't reuse the > > tranche? That might require creating a few more tranches, but ...? > > > > Andres > Do you mean moving LWLocks defined by offsets and with dynamic sizes > to separate tranches?
I think it is too much for the purpose. Only two new tranches and maybe one or some new members (maybe representing the group) of trances will do, I suppose. > It sounds like an good option, but it will require refactoring of > current tranches. In current implementation > i tried not change current things. Now one of the most controversial points of this patch is the details of the implement, which largely affects performance drag, maybe. >From the viewpoint of performance, I have some comments on the feature: - LWLockReportStat runs a linear search loop which I suppose should be avoided even if the loop count is rather small for LWLocks, as Fujii-san said upthread or anywhere. - Currently pg_stat_activity view is the only API, which would be a bit heavy for sampling use. It'd be appreciated to have a far lighter means to know the same informtion. > Simple solution will be using uint8 for tranche (because we have only > 3 of them now, > and it will take much time to get to 255) and uint8 for group. In this > case size will not change. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
