Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Ildus Kurbangaliev
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id 55AE2CD9.4050005@postgrespro.ru
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Andres Freund <andres@anarazel.de>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Fillfactor for GIN indexes
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [BUGS] object_classes array is broken, again