Re: Speed up Clog Access by increasing CLOG buffers
От | Tomas Vondra |
---|---|
Тема | Re: Speed up Clog Access by increasing CLOG buffers |
Дата | |
Msg-id | 43198bfb-391b-75da-0517-31e56c4d11f4@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: Speed up Clog Access by increasing CLOG buffers
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: