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 committed a patch > (48354581a49c30f5757c203415aa8412d85b0f70) to remove the spinlock from > a BufferDesc, which also reduces its size, I think, because it > replaces members of types BufFlags (2 bytes), uint8, slock_t, and > unsigned with a single member of type pg_atomic_uint32. > > The reason why these changes are relevant is because Andres thought > the observed regression might be related to the BufferDesc growing to > more than 64 bytes on POWER, which in turn could cause buffer > descriptors to get split across cache lines. However, in the > meantime, I did some performance tests on the same machine that Amit > used for testing in the email that started this thread: > > http://www.postgresql.org/message-id/ca+tgmozjda6k7-17k4a48rvb0upr98hvuancfnnlrgsdb1u...@mail.gmail.com > > The upshot of that is that (1) the performance degradation I saw was > significant but smaller than what Amit reported in the OP, and (2) it > looked like the patches Andres gave me to test at the time got > performance back to about the same level we were at before 6150a1b0. > So there's room for optimism that this is fixed, but perhaps some > retesting is in order, since what was committed was, I think, not > identical to what I tested.
That sounds like this open item is ready for CLOSE_WAIT status; is it? 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
