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
# .. .
...
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 [.
HI
On Wed, Dec 18, 2013 at 3:03 PM, Andres Freund wrote:
>
> 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 current test without t
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 [.
~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
|
|-
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
http://www.postgresql.org/message-id/20131201114514.gg18...@alap2.anaraz
Hi,
We recently observed ~15% performance regression with dbt2 from PG 9.3.
We narrowed down on testing master between 9.2 cut and 9.3 cut.
It seems that 0ac5ad5134f2769ccbaefec73844f8504c4d6182 is the culprit
commit.
We did several runs and perf profiling comparing it against its parent
(f9
