Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Ildus Kurbangaliev
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id 55AE2CD9.4050005@postgrespro.ru
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Andres Freund <andres@anarazel.de>)
Responses Re: RFC: replace pg_stat_activity.waiting with something more descriptive
List pgsql-hackers
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?
It sounds like an good option, but it will require refactoring of 
current tranches. In current implementation
i tried not change current things.

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.

-- 
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Fillfactor for GIN indexes
Next
From: Alvaro Herrera
Date:
Subject: Re: [BUGS] object_classes array is broken, again