Hi, As mentioned in my earlier mail i was not able to apply *pinunpin-cas-5.patch* on commit *6150a1b0, *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. Please refer to the attached performance report sheet for more insights. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/> On Sat, Mar 26, 2016 at 9:31 PM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote: > 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-n1wyouwwfhd6...@mail.gmail.com > <http://www.postgresql.org/message-id/capphfdsrot1jmsnrnccqpnzeu9vut7tx6b-n1wyouwwfhd6...@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.kapil...@gmail.com> > wrote: > >> On Wed, Mar 23, 2016 at 1:59 PM, Ashutosh Sharma <ashu.coe...@gmail.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-n1wyouwwfhd6...@mail.gmail.com >> >> With Regards, >> Amit Kapila. >> EnterpriseDB: http://www.enterprisedb.com >> > >
Performance_Results_with_pinunpin_cas_changes.xlsx
Description: MS-Excel 2007 spreadsheet
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
