On Mon, Sep 5, 2016 at 3:18 AM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Hi, > > This thread started a year ago, different people contributed various > patches, some of which already got committed. Can someone please post a > summary of this thread, so that it's a bit more clear what needs > review/testing, what are the main open questions and so on? >
Okay, let me try to summarize this thread. This thread started off to ameliorate the CLOGControlLock contention with a patch to increase the clog buffers to 128 (which got committed in 9.6). Then the second patch was developed to use Group mode to further reduce the CLOGControlLock contention, latest version of which is upthread [1] (I have checked that version still gets applied). Then Andres suggested to compare the Group lock mode approach with an alternative (more granular) locking model approach for which he has posted patches upthread [2]. There are three patches on that link, the patches of interest are 0001-Improve-64bit-atomics-support and 0003-Use-a-much-more-granular-locking-model-for-the-clog-. I have checked that second one of those doesn't get applied, so I have rebased it and attached it with this mail. In the more granular locking approach, actually, you can comment USE_CONTENT_LOCK to make it use atomic operations (I could not compile it by disabling USE_CONTENT_LOCK on my windows box, you can try by commenting that as well, if it works for you). So, in short we have to compare three approaches here. 1) Group mode to reduce CLOGControlLock contention 2) Use granular locking model 3) Use atomic operations For approach-1, you can use patch [1]. For approach-2, you can use 0001-Improve-64bit-atomics-support patch[2] and the patch attached with this mail. For approach-3, you can use 0001-Improve-64bit-atomics-support patch[2] and the patch attached with this mail by commenting USE_CONTENT_LOCK. If the third doesn't work for you then for now we can compare approach-1 and approach-2. I have done some testing of these patches for read-write pgbench workload and doesn't find big difference. Now the interesting test case could be to use few sub-transactions (may be 4-8) for each transaction as with that we can see more contention for CLOGControlLock. Few points to note for performance testing, one should use --unlogged tables, else the WAL writing and WALWriteLock contention masks the impact of this patch. The impact of this patch is visible at higher-client counts (say at 64~128). > I'm interested in doing some tests on the hardware I have available, but > I'm not willing spending my time untangling the discussion. > Thanks for showing the interest and let me know if something is still un-clear or you need more information to proceed. [1] - https://www.postgresql.org/message-id/CAA4eK1%2B8gQTyGSZLe1Rb7jeM1Beh4FqA4VNjtpZcmvwizDQ0hw%40mail.gmail.com [2] - https://www.postgresql.org/message-id/20160330230914.GH13305%40awork2.anarazel.de -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
use-granular-locking-v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
