On Tue, Apr 12, 2016 at 11:40:43PM -0400, Robert Haas wrote: > On Tue, Apr 12, 2016 at 10:30 PM, Noah Misch <n...@leadboat.com> 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, > unless Amit or somebody else turns up further evidence of a continuing > issue here. Thanks for testing again. > > If someone does retest this, it would be informative to see how the system > > performs with 6150a1b0 reverted. Your testing showed performance of > > 6150a1b0 > > alone and of 6150a1b0 plus predecessors of 008608b and 4835458. I don't > > recall seeing figures for 008608b + 4835458 - 6150a1b0, though. > > That revert isn't trivial: even what exactly that would mean at this > point is somewhat subjective. I'm also not sure there is much point. > 6150a1b08a9fe7ead2b25240be46dddeae9d98e1 was written in such a way > that only platforms with single-byte spinlocks were going to have a > BufferDesc that fits into 64 bytes, which in retrospect was a bit > short-sighted. Because the changes that were made to get it back down > to 64 bytes might also have other performance-relevant consequences, > it's a bit hard to be sure that that was the precise thing that caused > the regression. And of course there was a fury of other commits going > in at the same time, some even on related topics, which further adds > to the difficulty of pinpointing this precisely. All that is a bit > unfortunate in some sense, but I think we're just going to have to > keep moving forward and hope for the best. I can live with that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
