Re: Move PinBuffer and UnpinBuffer to atomics
| От | Alexander Korotkov |
|---|---|
| Тема | Re: Move PinBuffer and UnpinBuffer to atomics |
| Дата | |
| Msg-id | CAPpHfduH04sQ4yyyHpkXQAy2m8EZoOuRycSgw7+dCA92mP1Eog@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Move PinBuffer and UnpinBuffer to atomics (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Move PinBuffer and UnpinBuffer to atomics
|
| Список | pgsql-hackers |
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.
Alexander, I guess for r/w workload 5364b357 is a benefit on that
machine as well?I also think so. Alexander, if try read-write workload with unlogged tables, then we should see an improvement.
I'll try read-write workload.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: