Re: Speed up Clog Access by increasing CLOG buffers
От | Dilip Kumar |
---|---|
Тема | Re: Speed up Clog Access by increasing CLOG buffers |
Дата | |
Msg-id | CAFiTN-v2mO31VA7OSQ5-kp3e408diE0Y0=i_tmjcW54Bgu5uPQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Speed up Clog Access by increasing CLOG buffers
|
Список | pgsql-hackers |
On Tue, Sep 20, 2016 at 8:37 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > I think it is former (8 socket machine). I confirm this is 8 sockets machine(cthulhu) > > > You point related to high-client count is valid and I am sure it won't > give noticeable benefit at lower client-count as the the > CLOGControlLock contention starts impacting only at high-client count. > I am not sure if it is good idea to reject a patch which helps in > stabilising the performance (helps in falling off the cliff) when the > processes increases the number of cores (or hardware threads) > >> If you have to work that hard >> to find a big win, and tests under more reasonable conditions show no >> benefit, it's not clear to me that it's really worth the time we're >> all spending benchmarking and reviewing this, or the risk of bugs, or >> the damage to the SLRU abstraction layer. > > I agree with you unless it shows benefit on somewhat more usual > scenario's, we should not accept it. So shouldn't we wait for results > of other workloads like simple-update or tpc-b on bigger machines > before reaching to conclusion? +1 My test are under run, I will post it soon.. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: