Re: Performance degradation in commit 6150a1b0

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance degradation in commit 6150a1b0
Date: 2016-03-29 12:30:50
Message-ID: CAE9k0P=QCYFdiOCsy8VrmR0NHji9VgtNZ22PwEq_Ye1f65v2BA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I am unable to revert 6150a1b0 on top of recent commit in the master
branch. It seems like there has been some commit made recently that has got
dependency on 6150a1b0.

With Regards,
Ashutosh Sharma
EnterpriseDB: http://www.enterprisedb.com

On Sun, Mar 27, 2016 at 5:45 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2016-03-27 02:34:32 +0530, Ashutosh Sharma wrote:
> > As mentioned in my earlier mail i was not able to apply
> > *pinunpin-cas-5.patch* on commit *6150a1b0,
>
> That's not surprising; that's pretty old.
>
> > *therefore i thought of applying it on the latest commit and i was
> > able to do it successfully. I have now taken the performance readings
> > at latest commit i.e. *76281aa9* with and without applying
> > *pinunpin-cas-5.patch* and my observations are as follows,
> >
>
> > 1. I can still see that the current performance lags by 2-3% from the
> > expected performance when *pinunpin-cas-5.patch *is applied on the commit
> >
> > *76281aa9.*
> > 2. When *pinunpin-cas-5.patch *is ignored and performance is measured at
> > commit *76281aa9 *the overall performance lags by 50-60% from the
> expected
> > performance.
> >
> > *Note:* Here, the expected performance is the performance observed before
> > commit *6150a1b0 *when* ac1d794 *is reverted.
>
> Thanks for doing these benchmarks. What's the performance if you revert
> 6150a1b0 on top of a recent master? There've been a lot of other patches
> influencing performance since 6150a1b0, so minor performance differences
> aren't necessarily meaningful; especially when that older version then
> had other patches reverted.
>
> Thanks,
>
> Andres
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Aguayo Garcia-Rada 2016-03-29 12:38:10 Re: pg_largeobject
Previous Message lannis 2016-03-29 12:27:24 in drop database, auto-vacuum and immediate shutdown concurrency scene, hot-standby server redo FATAL