Re: [HACKERS] Performance degradation in commit 6150a1b0

On Wed, Apr 13, 2016 at 11:22 PM, Amit Kapila wrote: > Yes, I also think that this particular issue can be closed. However I felt > that the observation related to performance variation is still present as I > never need to perform prewarm or anything else to get consistent results > during my wo

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Wed, Apr 13, 2016 at 9:10 AM, Robert Haas wrote: > > On Tue, Apr 12, 2016 at 10:30 PM, Noah Misch wrote: > > That sounds like this open item is ready for CLOSE_WAIT status; is it? > > I just retested this on power2. Here are the results. I retested > 3fed4174 and 6150a1b0 plus master as of d

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Tue, Apr 12, 2016 at 11:40:43PM -0400, Robert Haas wrote: > On Tue, Apr 12, 2016 at 10:30 PM, Noah Misch wrote: > > That sounds like this open item is ready for CLOSE_WAIT status; is it? > > I just retested this on power2. > So, yes, I would say this should go to CLOSE_WAIT at this point, > u

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Tue, Apr 12, 2016 at 10:30 PM, Noah Misch wrote: > That sounds like this open item is ready for CLOSE_WAIT status; is it? I just retested this on power2. Here are the results. I retested 3fed4174 and 6150a1b0 plus master as of deb71fa9. 5-minute pgbench -S runs, scale factor 300, with predi

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Tue, Apr 12, 2016 at 05:36:07PM -0400, Robert Haas wrote: > So the current status of this issue is: > > 1. Andres committed a patch (008608b9d51061b1f598c197477b3dc7be9c4a64) > to reduce the size of an LWLock by an amount equal to the size of a > mutex (modulo alignment). > > 2. Andres also co

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 10:13 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Mar 31, 2016 at 6:45 AM, Andres Freund wrote: >>> On 2016-03-31 06:43:19 -0400, Robert Haas wrote: To which proposal are you referring? > >>> 1) in >>> http://www.postgresql.org/message-id/20160328130904.4mh

Re: [HACKERS] Performance degradation in commit 6150a1b0

Robert Haas writes: > On Thu, Mar 31, 2016 at 6:45 AM, Andres Freund wrote: >> On 2016-03-31 06:43:19 -0400, Robert Haas wrote: >>> To which proposal are you referring? >> 1) in >> http://www.postgresql.org/message-id/20160328130904.4mhugvkf4f3wg...@awork2.anarazel.de > OK. So, Noah, my propo

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 6:45 AM, Andres Freund wrote: > On 2016-03-31 06:43:19 -0400, Robert Haas wrote: >> On Thu, Mar 31, 2016 at 3:51 AM, Andres Freund wrote: >> >>My attribution above was incorrect. Robert Haas is the committer and >> >>owner of >> >>this one. I apologize. >> > >> > Fine in

Re: [HACKERS] Performance degradation in commit 6150a1b0

On 2016-03-31 06:43:19 -0400, Robert Haas wrote: > On Thu, Mar 31, 2016 at 3:51 AM, Andres Freund wrote: > >>My attribution above was incorrect. Robert Haas is the committer and > >>owner of > >>this one. I apologize. > > > > Fine in this case I guess. I've posted a proposal nearby either way, i

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 3:51 AM, Andres Freund wrote: >>My attribution above was incorrect. Robert Haas is the committer and >>owner of >>this one. I apologize. > > Fine in this case I guess. I've posted a proposal nearby either way, it > appears to be a !x86 problem. To which proposal are you

Re: [HACKERS] Performance degradation in commit 6150a1b0

On March 31, 2016 7:16:33 AM GMT+02:00, Noah Misch wrote: >On Thu, Mar 31, 2016 at 01:10:56AM -0400, Noah Misch wrote: >> 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

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 01:10:56AM -0400, Noah Misch wrote: > 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, > >

Re: [HACKERS] Performance degradation in commit 6150a1b0

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 though

Re: [HACKERS] Performance degradation in commit 6150a1b0

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 wro

Re: [HACKERS] Performance degradation in commit 6150a1b0

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 successf

Re: [HACKERS] Performance degradation in commit 6150a1b0

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 applyin

Re: [HACKERS] 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-n1wyouwwfhd6...@mail.gmail.com

Re: [HACKERS] Performance degradation in commit 6150a1b0

On 2016-03-25 09:29:34 +0530, Amit Kapila wrote: > > 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 poi

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Wed, Mar 23, 2016 at 1:59 PM, Ashutosh Sharma 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 lo

Re: [HACKERS] Performance degradation in commit 6150a1b0

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 mi

Re: [HACKERS] Performance degradation in commit 6150a1b0

On February 26, 2016 7:55:18 PM PST, Amit Kapila wrote: >On Sat, Feb 27, 2016 at 12:41 AM, Andres Freund >wrote: >> >> Hi, >> >> On 2016-02-25 12:56:39 +0530, Amit Kapila wrote: >> > From past few weeks, we were facing some performance degradation in >the >> > read-only performance bench marks i

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Sat, Feb 27, 2016 at 12:41 AM, Andres Freund wrote: > > Hi, > > On 2016-02-25 12:56:39 +0530, Amit Kapila wrote: > > From past few weeks, we were facing some performance degradation in the > > read-only performance bench marks in high-end machines. My colleague > > Mithun, has tried by reverti

Re: [HACKERS] Performance degradation in commit 6150a1b0

Hi, On 2016-02-25 12:56:39 +0530, Amit Kapila wrote: > From past few weeks, we were facing some performance degradation in the > read-only performance bench marks in high-end machines. My colleague > Mithun, has tried by reverting commit ac1d794 which seems to degrade the > performance in HEAD on

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Fri, Feb 26, 2016 at 8:41 PM, Simon Riggs wrote: > Don't understand this. If a problem is caused by one of two things, first > you check one, then the other. I don't quite understand how you think that patch can be decomposed into multiple, independent changes. It was one commit because every

Re: [HACKERS] Performance degradation in commit 6150a1b0

On 25 February 2016 at 18:42, Amit Kapila wrote: > On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs > wrote: > >> On 24 February 2016 at 23:26, Amit Kapila >> wrote: >> >>> From past few weeks, we were facing some performance degradation in the >>> read-only performance bench marks in high-end mac

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs wrote: > On 24 February 2016 at 23:26, Amit Kapila wrote: > >> From past few weeks, we were facing some performance degradation in the >> read-only performance bench marks in high-end machines. My colleague >> Mithun, has tried by reverting commit a

Re: [HACKERS] Performance degradation in commit 6150a1b0

On 24 February 2016 at 23:26, Amit Kapila wrote: > From past few weeks, we were facing some performance degradation in the > read-only performance bench marks in high-end machines. My colleague > Mithun, has tried by reverting commit ac1d794 which seems to degrade the > performance in HEAD on hi

[HACKERS] Performance degradation in commit 6150a1b0

>From past few weeks, we were facing some performance degradation in the read-only performance bench marks in high-end machines. My colleague Mithun, has tried by reverting commit ac1d794 which seems to degrade the performance in HEAD on high-end m/c's as reported previously[1], but still we were