Re: 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 <noah(at)leadboat(dot)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.