Re: Performance degradation in commit 6150a1b0

Hi,

I am getting some reject files while trying to apply "*pinunpin-cas-5.patch*"
attached with the thread,

*http://www.postgresql.org/message-id/CAPpHfdsRoT1JmsnRnCCqpNZEU9vUT7TX6B-N1wyOuWWfhD6F+g@mail.gmail.com
<http://www.postgresql.org/message-id/CAPpHfdsRoT1JmsnRnCCqpNZEU9vUT7TX6B-N1wyOuWWfhD6F+g@mail.gmail.com>*
Note: I am applying this patch on top of commit "
*6150a1b08a9fe7ead2b25240be46dddeae9d98e1*".

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

On Fri, Mar 25, 2016 at 9:29 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Wed, Mar 23, 2016 at 1:59 PM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
> wrote:
> >
> > Hi All,
> >
> > I have been working on this issue for last few days trying to
> investigate what could be the probable reasons for Performance degradation
> at commit 6150a1b0. After going through Andres patch for moving buffer I/O
> and content lock out of Main Tranche, the following two things come into my
> > mind.
> >
> > 1. Content Lock is no more used as a pointer in BufferDesc structure
> instead it is included as LWLock structure. This basically increases the
> overall structure size from 64bytes to 80 bytes. Just to investigate on
> this, I have reverted the changes related to content lock from commit
> 6150a1b0 and taken at least 10 readings and with this change i can see that
> the overall performance is similar to what it was observed earlier i.e.
> before commit 6150a1b0.
> >
> > 2. Secondly, i can see that the BufferDesc structure padding is 64 bytes
> however the PG CACHE LINE ALIGNMENT is 128 bytes. Also, after changing the
> BufferDesc structure padding size to 128 bytes along with the changes
> mentioned in above point #1, I see that the overall performance is again
> similar to what is observed before commit 6150a1b0.
> >
> > Please have a look into the attached test report that contains the
> performance test results for all the scenarios discussed above and let me
> know your thoughts.
> >
>
> So this indicates that changing back content lock as LWLock* in BufferDesc
> brings back the performance which indicates that increase in BufferDesc
> size to more than 64bytes on this platform has caused regression. I think
> it is worth trying the patch [1] as suggested by Andres as that will reduce
> the size of BufferDesc which can bring back the performance. Can you once
> try the same?
>
> [1] -
> http://www.postgresql.org/message-id/CAPpHfdsRoT1JmsnRnCCqpNZEU9vUT7TX6B-N1wyOuWWfhD6F+g@mail.gmail.com
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>