Subject: Re: Speed up Clog Access by increasing CLOG buffers
To: Amit Kapila <amit.kapila16@gmail.com>
References: 
 <CAA4eK1+8=X9mSNeVeHg_NqMsOR-XKsjuqrYzQf=iCsdh3U4EOA@mail.gmail.com>
 <0733fb9c-c3dc-fe30-1ad1-8c3ddf05c92d@2ndquadrant.com>
 <CAA4eK1J85_243PcJbG-AJoRq3wwZcc4xvMJEQ605Yz+1TXJpow@mail.gmail.com>
 <3dfb27e5-d3d3-20bb-2b35-3a0e2747625f@2ndquadrant.com>
 <CAA4eK1LOk=6omxO15fhhpaG4iOzdzW+9oMr=fh6nCeD37JvB6g@mail.gmail.com>
 <9e877db7-4dc2-88c1-67ae-034ad1a5cafe@2ndquadrant.com>
 <CA+Tgmoan8OxOfxCqiYr6T_Rc9qPFPBxWukBzi1xbGez1UpXx3Q@mail.gmail.com>
 <a87bfbfb-6511-b559-bab6-5966b7aabb8e@2ndquadrant.com>
 <CAA4eK1K7Jh1GxQeS+9-ZsadZpz+DfiCXVTjqk+X00aCV6gyP0g@mail.gmail.com>
 <26b69fb2-fa4d-530c-7783-1cb9d952c4e5@2ndquadrant.com>
 <781ac43c-da69-f5c7-a828-7b995691d4cc@2ndquadrant.com>
 <CAA4eK1K4HEsy819bkDxA3GxGBRsBvu9MmuGh3Q_CxUho29FG4A@mail.gmail.com>
 <5da94f12-8141-2f2f-016a-09a8e37bdd30@2ndquadrant.com>
 <CAA4eK1J1sJchNAsbbhKP1DSRubcZLtQuiTjWpxdF0rc9+QoXvg@mail.gmail.com>
 <e78b4f32-f24e-f282-1f46-b66d39d9ca9a@2ndquadrant.com>
 <f9a8572b-5f27-6666-0f44-e845480d989e@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
 Andres Freund <andres@anarazel.de>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <43198bfb-391b-75da-0517-31e56c4d11f4@2ndquadrant.com>
Date: Mon, 26 Sep 2016 20:48:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101
 Thunderbird/46.0a2
MIME-Version: 1.0
In-Reply-To: <f9a8572b-5f27-6666-0f44-e845480d989e@2ndquadrant.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 09/26/2016 07:16 PM, Tomas Vondra wrote:
>
> The averages (over the 10 runs, 5 minute each) look like this:
>
>  3.2.80                 1      8     16     32     64    128    192
> --------------------------------------------------------------------
>  granular-locking    1567  12146  26341  44188  43263  49590  15042
>  no-content-lock     1567  12180  25549  43787  43675  51800  16831
>  group-update        1550  12018  26121  44451  42734  51455  15504
>  master              1566  12057  25457  42299  42513  42562  10462
>
>  4.5.5                  1      8     16     32     64    128    192
> --------------------------------------------------------------------
>  granular-locking    3018  19031  27394  29222  32032  34249  36191
>  no-content-lock     2988  18871  27384  29260  32120  34456  36216
>  group-update        2960  18848  26870  29025  32078  34259  35900
>  master              2984  18917  26430  29065  32119  33924  35897
>
> That is:
>
> (1) The 3.2.80 performs a bit better than before, particularly for 128
> and 256 clients - I'm not sure if it's thanks to the reboots or so.
>
> (2) 4.5.5 performs measurably worse for >= 32 clients (by ~30%). That's
> a pretty significant regression, on a fairly common workload.
>

FWIW, now that I think about this, the regression is roughly in line 
with my findings presented in my recent blog post:

     http://blog.2ndquadrant.com/postgresql-vs-kernel-versions/

Those numbers were collected on a much smaller machine (2/4 cores only), 
which might be why the difference observed on 32-core machine is much 
more significant.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers