Hello,
At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru> wrote in
<55AE2CD9.4050005@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
havea 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