Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
От | Sergey Koposov |
---|---|
Тема | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Дата | |
Msg-id | alpine.LRH.2.02.1205311615280.6351@calx046.ast.cam.ac.uk обсуждение исходный текст |
Ответ на | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: 9.2beta1, parallel queries, ReleasePredicateLocks,
CheckForSerializableConflictIn in the oprofile
Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Список | pgsql-hackers |
On Thu, 31 May 2012, Robert Haas wrote: > > Thanks. How did you generate this perf report? It's cool, because I > haven't figured out how to make perf generate a report that is easily > email-able, and it seems you have. I did pretty much what you have said, e.g. attached it to running process by perf record -g -p PID and then perf report -g > output And postgresql was compiled with cflags=-g > > The only trouble is that there's no call stack information here for > s_lock or PinBuffer, which is what I really want. It seems to have > spit out call stack information only for the kernel functions, and not > for user functions. Yes, I forgot to clean the old binaries when recompiled with cflags=-g. So not it is fixed. I attach the updated perf report (i.e. the first 10000 lines of it to reduce the file size). Cheers, S ***************************************************** Sergey E. Koposov, PhD, Research Associate Institute of Astronomy, University of Cambridge Madingley road, CB3 0HA, Cambridge, UK Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/
В списке pgsql-hackers по дате отправления: