Re: Performance degradation in commit 6150a1b0

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Performance degradation in commit 6150a1b0
Дата
Msg-id 20160331051056.GD1502099@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Performance degradation in commit 6150a1b0  (Andres Freund <andres@anarazel.de>)
Ответы Re: Performance degradation in commit 6150a1b0  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sun, Mar 27, 2016 at 02:15:50PM +0200, Andres Freund wrote:
> 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.

[This is a generic notification.]

The above-described topic is currently a PostgreSQL 9.6 open item.  Andres,
since you committed the patch believed to have created it, you own this open
item.  If that responsibility lies elsewhere, please let us know whose
responsibility it is to fix this.  Since new open items may be discovered at
any time and I want to plan to have them all fixed well in advance of the ship
date, I will appreciate your efforts toward speedy resolution.  Please
present, within 72 hours, a plan to fix the defect within seven days of this
message.  Thanks.



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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Recovery test failure for recovery_min_apply_delay on hamster
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH v1] GSSAPI encryption support