Hello,
On 2013-12-18 10:24:56 -0800, Dong Ye wrote:
It seems that 0ac5ad5134f2769ccbaefec73844f8504c4d6182 is the culprit
commit.
How long does a run take to verify the problem? Could you retry with the
patch attached to
~20 minutes each run with binary.
Try your patch now..
You are right I used -g in perf record. But what I reported was flat (meant
as a start).
Expand GetMultiXactIdMembers:
3.82% postgres postgres [.]
GetMultiXactIdMembers
|
Hi,
On 2013-12-18 14:59:45 -0500, Dong Ye wrote:
~20 minutes each run with binary.
Try your patch now..
You are right I used -g in perf record. But what I reported was flat (meant
as a start).
Expand GetMultiXactIdMembers:
3.82% postgres postgres [.]
HI
On Wed, Dec 18, 2013 at 3:03 PM, Andres Freund and...@2ndquadrant.comwrote:
That looks like a postgres compiled without
-fno-omit-frame-pointer. Without that hierarchical profiles are
meaningless. Very new perfs can also do it using dwarf, but it's unusabl
slow...
Let me complete
Hi,
Applied your patch (but not using -fno-omit-frame-pointer). It seems
recover the perf loss: 55659.72 notpm.
FWIW, the profile is below. I will do a run with the flag..
Samples: 598K of event 'cycles', Event count (approx.): 6568957160059
+ 4.03% postgres postgres
Applying your patch plus adding -fno-omit-frame-pointer, I got 54526.90
notpm.
The profile (part) below:
# Samples: 610K of event 'cycles'
# Event count (approx.): 6686532056450
#
# Overhead Command Shared Object
Symbol
# .. .
