Re: Move PinBuffer and UnpinBuffer to atomics
| От | Amit Kapila |
|---|---|
| Тема | Re: Move PinBuffer and UnpinBuffer to atomics |
| Дата | |
| Msg-id | CAA4eK1LE3h1duMPOwc5BOLCfPyiU-jHcjy5VYKaH0vaJXao0Yw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Move PinBuffer and UnpinBuffer to atomics (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
| Ответы |
Re: Move PinBuffer and UnpinBuffer to atomics
|
| Список | pgsql-hackers |
On Sun, Apr 10, 2016 at 11:10 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Sun, Apr 10, 2016 at 7:26 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:On Sun, Apr 10, 2016 at 1:13 AM, Andres Freund <andres@anarazel.de> wrote:On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote:
> There are results with 5364b357 reverted.What exactly is this test?I think assuming it is a read-only -M prepared pgbench run where data fits in shared buffers. However if you can share exact details, then I can try the similar test.Yes, the test is:pgbench -s 1000 -c $clients -j 100 -M prepared -S -T 300 (shared_buffers=24GB)Crazy that this has such a negative impact. Amit, can you reproduce
that?I will try it.Good.
Okay, I have done some performance testing of read-only tests with configuration suggested by you to see the impact
pin_unpin - latest version of pin unpin patch on top of HEAD.
pin_unpin_clog_32 - pin_unpin + change clog buffers to 32
| Client_Count/Patch_ver | 64 | 128 |
| pin_unpin | 330280 | 133586 |
| pin_unpin_clog_32 | 388244 | 132388 |
This shows that at 64 client count, the performance is better with 32 clog buffers. However, I think this is more attributed towards the fact that contention seems to shifted to procarraylock as to an extent indicated in Alexandar's mail. I will try once with cache the snapshot patch as well and with clog buffers as 64.
В списке pgsql-hackers по дате отправления: