Subject: Re: Speed up Clog Access by increasing CLOG buffers
To: Robert Haas <robertmhaas@gmail.com>
References: 
 <CAA4eK1+8=X9mSNeVeHg_NqMsOR-XKsjuqrYzQf=iCsdh3U4EOA@mail.gmail.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>
 <43198bfb-391b-75da-0517-31e56c4d11f4@2ndquadrant.com>
 <d7a7e096-daac-9207-8eae-50f450203312@2ndquadrant.com>
 <CA+TgmoZ+2OmyUfcNOPsFwsBXJdBcKKPnLaFJ3DJyYLop0u_OLQ@mail.gmail.com>
Cc: Amit Kapila <amit.kapila16@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: <e654de76-0aaa-2873-e105-b6a358e59894@2ndquadrant.com>
Date: Thu, 29 Sep 2016 00:45:15 +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: 
 <CA+TgmoZ+2OmyUfcNOPsFwsBXJdBcKKPnLaFJ3DJyYLop0u_OLQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 09/28/2016 05:39 PM, Robert Haas wrote:
> On Tue, Sep 27, 2016 at 5:15 PM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> So, I got the results from 3.10.101 (only the pgbench data), and it looks
>> like this:
>>
>>  3.10.101               1      8     16     32     64    128    192
>> --------------------------------------------------------------------
>>  granular-locking    2582  18492  33416  49583  53759  53572  51295
>>  no-content-lock     2580  18666  33860  49976  54382  54012  51549
>>  group-update        2635  18877  33806  49525  54787  54117  51718
>>  master              2630  18783  33630  49451  54104  53199  50497
>>
>> So 3.10.101 performs even better tnan 3.2.80 (and much better than 4.5.5),
>> and there's no sign any of the patches making a difference.
>
> I'm sure that you mentioned this upthread somewhere, but I can't
> immediately find it.  What scale factor are you testing here?
>

300, the same scale factor as Dilip.

>
> It strikes me that the larger the scale factor, the more
> CLogControlLock contention we expect to have.  We'll pretty much do
> one CLOG access per update, and the more rows there are, the more
> chance there is that the next update hits an "old" row that hasn't
> been updated in a long time.  So a larger scale factor also
> increases the number of active CLOG pages and, presumably therefore,
> the amount of CLOG paging activity.
 >

So, is 300 too little? I don't think so, because Dilip saw some benefit 
from that. Or what scale factor do we think is needed to reproduce the 
benefit? My machine has 256GB of ram, so I can easily go up to 15000 and 
still keep everything in RAM. But is it worth it?

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