On Thu, Mar 31, 2016 at 10:13 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Mar 31, 2016 at 6:45 AM, Andres Freund <and...@anarazel.de> 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 proposed strategy is to wait and see if Andres can >> make that work, and if not, then revisit the issue of what to do. > > I thought that proposal had already crashed and burned, on the grounds > that byte-size spinlocks require instructions that many PPC machines > don't have.
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
