Re: Move PinBuffer and UnpinBuffer to atomics - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Move PinBuffer and UnpinBuffer to atomics
Date
Msg-id CAPpHfduH04sQ4yyyHpkXQAy2m8EZoOuRycSgw7+dCA92mP1Eog@mail.gmail.com
Whole thread Raw
In response to Re: Move PinBuffer and UnpinBuffer to atomics  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Move PinBuffer and UnpinBuffer to atomics  (Amit Kapila <amit.kapila16@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Next
From: Noah Misch
Date:
Subject: Re: [COMMITTERS] pgsql: Bloom index contrib module