Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Дата
Msg-id CAMkU=1w9jFQibraAB8SBZjvwteR=RPm7kV_PsGucGckBOOe1dA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Ответы Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Список pgsql-hackers
On Thu, May 24, 2012 at 3:36 PM, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:
> Hi,
>
>
> On Thu, 24 May 2012, Robert Haas wrote:
>>
>> Not sure.  It might be some other LWLock, but it's hard to tell which
>> one from the information provided.
>
>
> If you could tell what's the best way to find out the info that you need,
> then I could run it reasonably quickly.

Add
#define LWLOCK_STATS
near the top of:
src/backend/storage/lmgr/lwlock.c

and recompile and run a reduced-size workload.  When the processes
exits, they will dump a lot of data about LWLock usage to the logfile.Generally the LWLock with the most blocks on it
willbe the main 
culprit.

Cheers,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: [RFC] Interface of Row Level Security
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Draft release notes complete